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
Andrew Cagney writes:
> Solution 0 is to discard the STOP in infrun.c as part of the stop
> analyzis.
>
Yes, but I am not sure it won't break the other cases that share that
stop analysis. The stop_soon_quietly variable is relied upon in other
places, like the start_remote function, the startup_inferior function,
the sharedlib machinery. That's why I thought the handling it in the
attach command would be safer.
> > 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.
>
Hmm true, sigh.
> > 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()?
>
yes, proceed() already does something like that, but that would mean
that we modify the signal before doing the continue, and not after we
receive it. There is a lot that can happen between issuing an
'attach' command, and a later 'continue'. Maybe we would be discarding
a valid SIGSTOP to pass to the inferior.
I think the only option left is to change the handle_inferior_event
stop analysis, which is scary...
> 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