Re: [RFC] PTRACE_ATTACH problem on new Linux kernels

[Daniel Jacobowitz <drow@mvista.com>]

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.

> 
> > 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?

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