Re: Feature Parity: Remote fork following

On 08/06/2013 06:10 AM, Pedro Alves wrote:
> 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.
>
>

Ah, that's what i was talking about. Somehow i had in mind the old 
"remote" target would deal with thing with no PID's whatsoever.

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

Yeah. server-side for this starts to sound like a potentially broken 
path for now.