RE: Debugging threaded processes -- ptrace proposal

["Paul Koning" <Paul_Koning%Dell.com@localhost>]

Updated proposal:

In the existing implementation, even though the manpage doesn't say so,
PT_STEP will take the value in the data argument (4th argument) as the
signal to deliver, exactly as for PT_CONTINUE.  (For that matter, it
also looks at the 3rd argument, addr, in the same way as PT_CONTINUE.)
So for consistency, I would propose that a negative value in the data
argument is used to specify an LWP ID in both cases (the ID being the
absolute value of what's passed).

        paul

> -----Original Message-----
> From: Paul Koning
> Sent: Friday, March 19, 2010 1:07 PM
> To: tech-kern%NetBSD.org@localhost
> Subject: RE: Debugging threaded processes -- ptrace proposal
> 
> Gentlepeople,
> 
> It's clear that GDB requires a way to step and resume single threads,
> which currently doesn't exist.  (I checked the analogous procfs
> machinery -- it doesn't have that either, and in fact it is behind
> ptrace because it doesn't even have a way to do *any* operations on
> threads other than the first one.)
> 
> The minimal change I can see is to add a way to select the thread to
> operate on in PT_STEP and PT_CONTINUE.
> 
> For PT_STEP that's easy: use the "data" argument as the LWPID if non-
> zero, exactly as is already done for PT_GETREGS and the like.
> 
> For PT_CONTINUE it's a bit harder, because there aren't any unused
> arguments.  A way to deal with this uses the fact that single thread
> resume never wants to deliver a signal (which makes sense, because
> signals go to processes).  So I propose to use the "data" argument
with
> a negative value (the negative of the LWPID) to mean "continue only
> this thread".
> 
> Comments?  Alternative/better ways of doing this?
> 
>       paul