Re: ptrace(2) PT_STEP changes and gdb

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

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.

(2) is clearly more work; I'm not sure it's worth the trouble.  I would prefer 
(1).

        paul