Re: Feature Parity: Remote fork following

[Pedro Alves <palves at redhat dot com>]

On 08/05/2013 07:46 PM, Luis Machado wrote:

> Risking creating more work, how does it sound to require even the 
> single-process (target remote) mode to use PID's for context, just like 
> the extended-remote mode does? I wonder how hard that is and how much 
> work is involved there. Implementing single-process mode on top of 
> multi-process... similar to all-stop on top of non-stop.

I'm confused.  Is that any different from:

On 07/24/2013 12:45 PM, Pedro Alves wrote:
>> Originally, the multi-process extensions were always off if you connected
>> with "target remote"; they'd only be available to extended-remote.  But
>> nowadays that's no longer true -- multi-process is always available even
>> in "target remote", if the target supports them.  The push in that direction
>> had follow-fork in mind.  So, if multi-process extensions make this easier,
>> we can just require them.

> 
> A big problem is backwards compatibility in this case. There are a bunch 
> of gdbserver/gdb versions out there that would try to speak to each 
> other without mentioning PID's no matter what.

Support for the multi-process extensions is broadcast in qSupported
("multiprocess+").  This works presently.  Try connecting to gdbserver
with plain "target remote", and you'll see PIDs.  But if the target
doesn't support the extension, then GDB will still cope.  It just wont
support certain things.  Fork would just be another of those things.


>> GDB needs to undo things from the child before detaching it
>> (gdb-side breakpoints, displaced stepping, etc.).  Only if it's really
>> sure nothing will need to be removed, could pushing follow-fork-mode/detach-on-fork
>> to the remote side be useful.  I do believe such an optimization (where
>> the target handles fork following) might be useful for plain "continue until
>> SEGV in some child" scenario, but otherwise, I believe it to be better to start
>> with the basics first.  Make catch fork/vfork/exec work, and build up from
>> that.  Proper vfork handling, where you have shared memory region between parent/child
>> until TARGET_WAITKIND_VFORK_DONE (which needs RSP modelling as well) also needs to
>> be factored in.
> 
> Handling these events inside gdbserver seems to be more straightforward 
> than doing back-and-forth to inform GDB of things that are happening.
> 
> The problem i see is the lack of displaced stepping support in 
> gdbserver. Everything is controlled by GDB in this case. In the future, 
> i imagine displaced stepping will just disappear and the debugger will 
> just ask for "stepi/step" and things will happen.

Sure, that's certainly possible, but I'm also certain that there'll always
be corner cases of run control where GDB will need to be informed of the fork
events, even if most handling can be done 99% of the time of the program
run in the server.  "catch fork" is the most obvious example.  New
fork events are a necessary condition to support these catchpoints, and
everything else can be built on top, while anything beyond the
catchpoints can be seen as optimization work, IMO.  Even then, you're
_requiring_ always implementing breakpoints on the server-side that
way -- that complicates the server-side work to support forks on
software single-step targets (ARM, etc.), by a whole lot.  Seems desirable
to support those too, without too many requirements.

-- 
Pedro Alves