ptrace(2) PT_STEP changes and gdb

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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