Re: [RFC] PTRACE_ATTACH problem on new Linux kernels

[Elena Zannoni <ezannoni@redhat.com>]

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