Re: ptrace(2) PT_STEP changes and gdb

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

On Aug 17, 2010, at 11:07 AM, Joerg Sonnenberger wrote:

> Hi all,
> the recent changes for ptrace(2) to allow thread debugging had the
> unintentional side effect of breaking single stepping in the existing
> GDB in some cases. I have one binary here where setting a conditional
> break point consistently results in ptrace(2) returning ESRCH.
> 
> 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.

That's clearly one possibility.  If that is done, PT_STEP would not longer be 
used at all in GDB.

Given that previously the data argument was ignored yet it was being passed as 
a signal number, I would argue the original code had a bug.  (Either that, or 
it was just a pointless accident -- if the signal wasn't actually needed for 
anything.)  If so, given that the question is on the in-tree GDB, isn't the 
simplest answer to fix GDB so it doesn't pass the bad value?

If the goal is to allow older GDB binaries to continue to run, that's a 
different matter.  But in fact such binaries don't function in a useful way 
except with single-threaded applications, so keeping them running doesn't seem 
like a particularly interesting goal.

        paul