This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] PTRACE_ATTACH problem on new Linux kernels
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