> I agree that making the interface stateless would be a good thing.
> 
> A few loose ends:
> 
>  - How does the debugger identify *which* LWP took the signal which
> stopped the child?  What about "simultaneous" faults -- i.e., multiple
> LWP's take faults before the non-faulting LWPs are suspended?


This isn't a loose end.  It is where your fun begins.

Are you refering to the interface, a debugger, or GDB (retorical 
question).  GDB's current model (good or bad) is that only one thread 
causes the process to stop.  For the user to see the reason for the next 
lwp, they need to issue a target resume command.  Beneth the covers GDB 
migh resume the target or it might just pretend to immediatly returning 
the next threads stop reason.

The only hint I can give is ``don't lie''.  If several threads can end 
up with signals then, make that information available.  Leave it to the 
debugger and its thread module to sort out the mess.  Rebuilding GDB is 
easier than rebuilding the kernel.

HP/UX has ttrace_wait().  I don't know if that is a good or bad idea.


>  - How does the debugger enumerate the set of LWP's in the process?
> 
>  - One thing to consider would be a mode (for single-stepping) where
> an LWP of interest is allowed to run (briefly) while other LWP's in
> the same process are left suspended.


Yes please!  This is important since it makes it possible to do a 
``thread hop'' - where you need to step a single thread off of its 
memory breakpoint without allowing any of the other threads to proceed.

A second often requested feature being able to suspend/resume specific 
threads.  Way beyond the current capacity of gdb.  Just keep it in mind.

	Andrew