Re: [RFC] PTRACE_ATTACH problem on new Linux kernels

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > On Mon, Feb 17, 2003 at 09:24:01PM -0500, Andrew Cagney wrote:
 > > Solution 0 is to discard the STOP in infrun.c as part of the stop
 > > analyzis.
 > 
 > I like this; but I can't think how to do it without some global state
 > bit saying just-attached-expecting-SIGSTOP.
 > 

We kind of have it already, it is stop_soon_quietly, I am not sure it
is specific enough though.

 > > 
 > > > 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.
 > 
 > I'm not sure what Solaris does - don't we use procfs instead of ptrace
 > there anyway?  Do we still get a SIGSTOP at attach?

Unless I was hallucinating gdb was getting a SIGSTOP and passing that
down to resume, later. I'll look again.

 > 
 > But Roland made a very convincing case for this new behavior; for
 > programs like strace which just pass all signals through, this prevents
 > SIGSTOPs being silently cancelled, which is a definite plus.
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer