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