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