Re: [RFC] Fork and Exec events with target remote

[Pedro Alves <palves at redhat dot com>]

On 10/09/2015 08:09 PM, Don Breazeal wrote:
> Hi
> 
> I've been working on implementing support for fork and exec
> events in target remote mode (as opposed to extended-remote).
> 
> I have a patchset that is working to some degree, but there are
> some areas of ambiguity related to what the behavior should be
> in remote mode.  I list some of the major ones below.  I'd
> appreciate feedback on how this matches expectations before
> finalizing my patches.
> 
> Sorry for the length of this, but I have a lot of questions.
> 
> 1) Remote vs Extended
> My first question isn't specific to my patchset, but is important
> relative to the rest of my questions and proposals.
> 
>  * What is the *current* purpose of each of the remote protocols, i.e.
> why have more than one?

There are a few minor differences here and there, but the
only difference that really matters I think is what happens when
the debugged process exits.  extended-remote stays connected,
remote disconnects.

> 
>  * What is the long-term plan for each of them?  Will they eventually
> merge into one?

I'd very much like that to happen.  It always felt to me that
"extended" was first added as a separate target to avoid changing
existing stubs, with the idea that things would be merged later on.
That was all before my time, so I'm just guessing.  It'll take someone
to evaluate the current use cases (and try things against a few different
stubs; e.g., qemu, gdbserver, valgrind, some deep embedded stub) and come up
with a better model.  It may be that e.g., we can make gdb always
try enabling extended remote, and leave disconnecting or not to
the server side.  Or we add a "set remote disconnect-after-kill/detach/exit on/off"
knob to split out that decision from the initial connection.  Or maybe
something else.  It could also be that we could simplify things on the gdbserver
side and get rid of the gdbserver --multi option.  I never gave it a
deep enough think.


> 7) Enable/Disable tests for remote mode
> Many of the remote fork and exec tests were guarded from running in
> remote mode by something similar to this:
> 
> if { [is_remote target] || ![isnative] } then {
>     continue
> }
> 
> To enable these tests I've just deleted these blocks.
> 
> For tests that need to be disabled for remote mode, I've diverged
> from the usual practice (above) by using this:
> 
> if { [target_info exists gdb_protocol] } then {
>     if { [target_info gdb_protocol] == "remote" } then {
>         continue
>     }
> }
> 
> This makes more sense to me than 'is_remote target' etc, since it is
> checking the thing we really care about: whether we are using remote
> mode or not.

Right.

> 
> 8) Documentation
> Since target remote mode will support multi-process debugging with
> this patchset, the documentation requires some reorganization.
> Previously, target extended-remote mode was not described in the
> section on connecting to gdbserver.  It was in a section under "Running
> gdbserver" named "Multi-process mode for gdbserver".  The concept of
> multi-process == target extended-remote mode is going away, so that
> organization no longer makes sense.  I'm hopeful that the answers to my
> question (1) above will clarify how to draw this distinction in the
> revised docs.

Yeah, the "multi-process" referred to, in that section is about being able
to debug another process after the previous exited.  That is, to the fact that
the connection doesn't close after the process exits.  It's different
from the "multi-process" idea of being able to run multiple
processes _simultaneously_.  Cleaning all that up will be greatly appreciated!
It's been on my wish list for long.

> 
> It looks like the documentation distinguishes between remote and
> extended-remote using "@kbd{target remote} mode" and "@kbd{target
> extended-remote} mode". I plan to follow that approach barring any
> objections.

Thanks,
Pedro Alves