Re: ptrace(2) PT_STEP changes and gdb

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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.

Joerg