Re: ptrace(2) PT_STEP changes and gdb

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 17 Aug 2010, Paul Koning wrote:

> On Aug 17, 2010, at 2:15 PM, Joerg Sonnenberger wrote:
> 
> > On Tue, Aug 17, 2010 at 10:10:17PM +0400, Valeriy E. Ushakov wrote:
> >> On Tue, Aug 17, 2010 at 17:07:14 +0200, Joerg Sonnenberger wrote:
> >> 
> >>> 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.
> >> 
> >> Can't you just version it?  Rename existing PT_STEP to PT_OSTEP or
> >> something, define PT_STEP with the new value (instead of introducing
> >> new PT_* name)?
> > 
> > That would be one approach. It would still be leave someone compiling
> > gdb from source to discover such surprises, but I am not sure if we
> > care.
> 
> Clearly GDB needs to be fixed if it's broken.  
> 
> Renaming PT_STEP doesn't seem like a good idea.  That protects binaries but 
> it breaks source, in a surprising way.  The two options that make sense to me 
> are (1) leave ptrace as it is now -- so old code that does PT_STEP with 
> non-zero data needs correction, and (2) revert PT_STEP to what it was, adding 
> new PT_LWPSTEP to do what PT_STEP does in Current -- and change GDB to match.

(3) if the process only has one thread ignore he argument.

Eduardo