tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ptrace(2) PT_STEP changes and gdb
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
Home |
Main Index |
Thread Index |
Old Index