Re: ptrace(2) PT_STEP changes and gdb

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

On Aug 17, 2010, at 4:55 PM, Joerg Sonnenberger wrote:

> On Tue, Aug 17, 2010 at 03:21:17PM -0400, Paul Koning wrote:
>> Let me suggest a simpler solution.
> 
> Fine with me :)
> 
>> The problem is in the meaning of the data argument in PT_STEP.
> 
> Yes.
> 
>> The others (in particular PT_CONTINUE) use positive value of data to
>> mean signum, and negative to mean LWP ID.
> 
> Yes. This is a bit problematic too, see below.
> 
>> 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.
> 
> The threading support in ptrace(2) seems quite a bit hacked and this is
> one of them. As mentioned above, there is no clean interface to provide
> the effect of _lwp_kill. There is no interface to provide the effect of
> _lwp_unpark. The above seems to assume that I want to only ever single
> step through a single thread. So why isn't the interface providing the
> following primitives:
> STOP: like SIGSTOP
> CONTINUE: inverse of STOP
> SIGNAL: push signal frame on the stack, but don't otherwise alter state
> STEP: switch to single stepping mode
> WAKEUP: like _lwp_unpark.
> in a version of single thread and all threads.

Well, that's certainly possible.

The threading support looks the way it does because it had a simple goal: to 
extend the previous semantics in a way that supports the threading primitives 
needed by GDB.  My reasons for doing it were to get thread debug support for 
NetBSD (which, bafflingly, shipped 5.0 without this).  By and large the new 
ptrace() does this, though obviously you have identified a bug.

Yes, one could implement a completely new set of ptrace-like functions along 
the lines you describe.  It would have to be a new syscall because what you 
describe isn't ptrace, though it looks a bit like it.  Then the NetBSD target 
dependent code in GDB could be rewritten to use these new primitives.

A very different but equally viable proposal came from Matt Thomas: implement 
an interface (say, via /proc) that speaks the GDB remote stub protocol.  That's 
a well defined way to express GDB operations including thread operations.

Either one of these options (the second one especially) is a very much larger 
job.  If people judge it worth doing I certainly won't object, but I'm not all 
that inclined to sign up for it.  

        paul