[RFC] Fork and Exec events with target remote

[Don Breazeal <donb at codesourcery dot com>]

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?

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

2) Multiprocess support
Target remote mode will allow debugging of multiple inferiors.

3) Gdbserver exit
In target remote mode, gdbserver will no longer exit as soon as any
inferior terminates.  Instead, it will exit when there are no more
active inferiors.  This contrasts with extended mode, where gdbserver
exits when explicitly requested via "monitor exit", or when using the
'--once' option, when GDB exits.

4) Run command in remote mode
Gdbserver will still not support the 'run' command in target remote
mode.  This has a big effect on subsequent issues.

5) Follow-exec-mode won't be useful in target remote mode
Follow-exec-mode is used to specify how GDB determines the inferior to
re-run after the inferior has called exec.  Although this patch
implements support for fork and exec events in remote mode, it doesn't
implement re-running an inferior.

6) Test restrictions
Remote mode tests that expect to re-run the inferior using [runto_main]
need a clean_restart before runto_main, since the run command isn't
supported in remote mode, and the expectation is that the inferior will
be restarted.

Tests that use 'set args' to set program arguments can't run in remote
mode, since the program is loaded before the arguments can be set via
'set args' and can't restart it.

Tests that expect to be able to continue debugging after all inferiors
have terminated can't run in remote mode, since gdbserver will have
exited.

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.

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.

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!
--Don