This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]