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
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc:
- Date: Tue, 8 Apr 2003 14:57:53 -0400
- Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels
- References: <15953.34032.985446.344226@localhost.redhat.com><20030218022401.14C7E3CF3@localhost.redhat.com><15953.43345.841483.153044@localhost.redhat.com><3E52936A.3060706@redhat.com><15954.39904.805543.819269@localhost.redhat.com>
Elena Zannoni writes:
> Andrew Cagney writes:
> > > 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
> >
> >
>
> Kind of. I am testing the following:
>
> 2003-02-18 Elena Zannoni <ezannoni at redhat dot com>
>
> * infrun.c (stop_soon_quietly): Make it an enum, to better
> override the default behavior of handle_inferior_event.
> (clear_proceed_status): Update uses of stop_soon_quietly to
> reflect that it is now an enum.
> (start_remote): Ditto.
> (handle_inferior_event): Change logic a bit if stop_soon_quietly
> is set to handle the new kernel behavior for attach/sigstop.
> Update uses of stop_soon_quietly.
> * inferior.h (enum stop_kind): New enum.
> * infcmd.c (attach_command): Use STOP_QUIETLY_NO_SIGSTOP.
> Reset normal handle_inferior_event behavior, afterwards.
> * fork-child.c (startup_inferior): Update.
> * alpha-tdep.c (heuristic_proc_start): Update.
> * solib-svr4.c (svr4_solib_create_inferior_hook): Update.
> * solib-sunos.c (sunos_solib_create_inferior_hook): Update.
> * solib-osf.c (osf_solib_create_inferior_hook): Update.
> * solib-irix.c (irix_solib_create_inferior_hook): Update.
> * remote-vx.c (vx_create_inferior): Update.
> * mips-tdep.c (heuristic_proc_start): Update.
>
>
I finally committed this. I'll do another round changing the name of
stop_soon_quietly to stop_soon, as Kevin suggested.
elena