[RFC] PTRACE_ATTACH problem on new Linux kernels

[Andrew Cagney]

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

It certainly doesn't break anything, however, it also makes the long 
term problem harder.

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

Think about the frames code where things got so complicated that no one 
was game to change it.
With the changes in place I'm now finding my self fighting a rear-guard 
action to stop the old hacks re-appearing.

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

Conceptually, the code is being used as:

- connect to target
- force the WFI state machine into a specific initial state (stop 
normally, stop_soon_quietly or, now, stop_soon_with_sigstop) (yes, ok, 
no one believes me when I say that WFI is a state machine :-)
- run the WFI state machine to analize the target's state

Can stop_soon_quietly be [ab]used / extended to in a more general way 
force WFI into other states?  Either by treating it as bit fields or as 
alternative states?  e.g.,

enum stop_soon { stop_soon_normally, stop_soon_quietly, 
stop_soon_suspended };

or struct stop_soon { int quietly; int suspended; }

or ...

Andrew