Re: [RFC] PTRACE_ATTACH problem on new Linux kernels

[ac131313@redhat.com (Andrew Cagney)]

Solution 0 is to discard the STOP in infrun.c as part of the stop
analyzis.

> A first solution could be that upon continuing, gdb never sends a
> SIGSTOP through the ptrace call. I.e. the stop_signal in
> ptrace(PTRACE_CONT, pid, stop_signal) could be changed to
> TARGET_SIGNAL_0 if it is TARGET_SIGNAL_STOP (such a call is in
> proceed(), and we already do some signal munging there).
> 
> Another solution is to throw away the TARGET_SIGNAL_STOP that is saved
> in stop_signal when we do an attach. This would be in
> attach_command(), in infcmd.c. This way it would not come into play at
> all at the next continue.

This will make the desperatly needed objective of trying to eliminate
the global stop_signal variable just that bit more difficult.

If the already nasty hacks in HP/PA and solib code is ignored, the
only places stop_signal is modified is in infrun.c.

> Yet another solution is that we 'hide' the TARGET_SIGNAL_STOP in
> child_resume(), in i386-linux-nat.c but this would not be applicable
> to the other linux arches.

Or discard the signal in resume()?

Regardless, remembering that GDB is just one client of the kernel, the
kernel group should probably also restore the behavour that is
conistent with solaris and (most likely) every other ptrace
implementation.

Andrew