Re: ptrace(2) PT_STEP changes and gdb

[Paul Koning <paul_koning%dell.com@localhost>]

On Aug 17, 2010, at 11:07 AM, Joerg Sonnenberger wrote:

> Hi all,
> the recent changes for ptrace(2) to allow thread debugging had the
> unintentional side effect of breaking single stepping in the existing
> GDB in some cases. I have one binary here where setting a conditional
> break point consistently results in ptrace(2) returning ESRCH.
> 
> Problem is that historically PT_STEP's data argument was ignored and the
> in-tree gdb has one case where it provides a signal number as data.
> 
> What is the best solution? From looking at all the cases, I think the
> only sane approach is to add a new request PT_LWPSTEP.

Let me suggest a simpler solution.

The problem is in the meaning of the data argument in PT_STEP.  The others (in 
particular PT_CONTINUE) use positive value of data to mean signum, and negative 
to mean LWP ID.

PT_STEP needs to do two things: (a) step just one thread (the others don't 
execute) and (b) step one thread while continuing the others.  Since I thought 
that "data" was not used in PT_STEP I used positive vs. negative values to 
distinguish the two cases of thread stepping.

It turns out that this is not right.  In fact, the manpage can be read to say 
that PT_STEP with a signal is supported, because it says that it's just like 
PT_CONTINUE apart from stopping soon.

So... how about if we fix PT_STEP so it can deliver signals (positive data) or 
do the two flavors of thread stepping?  The question is how to encode that.  
The use of negative data to mean LWP ID implies that the current code assumes 
LWP IDs are at most 31 bits.  (I hope that's valid...)  Can we assume them to 
be at most 30 bits?  If yes, then bit 30 can encode the "step one, stop rest" 
vs "step one, continue rest" choice.

        paul