Re: [RFC] PTRACE_ATTACH problem on new Linux kernels

[Elena Zannoni <ezannoni at redhat dot 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