tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

ptrace(2) PT_STEP changes and gdb

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.


Home | Main Index | Thread Index | Old Index