Subject: Re: ptrace(2) + nathanw_sa LWPs
To: None <firstname.lastname@example.org>
From: Andrew Cagney <email@example.com>
Date: 12/10/2001 09:16:29
> 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.