Re: ptrace(2) PT_STEP changes and gdb

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

On Aug 17, 2010, at 4:46 PM, Eduardo Horvath wrote:

> 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.

That means the semantics of ptrace can change out from under the program using 
it.  If it passes an argument to PT_STEP because there are two threads, and one 
thread exits before the ptrace() call actually runs, then the argument would be 
ignored producing an unexpected result.

        paul