[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
ptrace(2) PT_STEP changes and gdb
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.
Main Index |
Thread Index |