Multiple process support in gdbserver

[Daniel Jacobowitz <drow@false.org>]

(Don't get too excited by the subject - just one process at a time, for
now.  But we may extend the same code for multiple simultaneous
processes once the Ericsson multi-process debugging work that Jim
Blandy posted about is finished.)

During my port of GDB to SymbianOS, I added support for a persistant
remote debug agent which can start new processes or attach to already
running processes.  I cleaned up the limited "extended-remote" support
in gdbserver and added support for a state with nothing running at
all.  Now I can connect to an idle gdbserver, specify a program and
command line arguments, and tell it to "run" just like a native
GDB.

I'll be posting the implementation to gdb-patches in just a moment;
first, here's the user interface and protocol changes.  All comments
welcome, either here or on the code.

Here's the gdbserver user model:

@subsubsection Multi-Process Mode for @code{gdbserver}

When you connect to @code{gdbserver} using @code{target remote},
@code{gdbserver} debugs the specified program only once.  When the
program exits, or you detach from it, @value{GDBN} closes the connection
and @code{gdbserver} exits.

If you connect using @code{target extended-remote}, @code{gdbserver}
enters multi-process mode.  When the debugged program exits, or you
detach from it, @value{GDBN} stays connected to @code{gdbserver} even
though no program is running.  The @code{run} and @code{attach}
commands instruct @code{gdbserver} to run or attach to a new program.
The @code{run} command uses @code{set remote exec-file} (@pxref{set
remote exec-file}) to select the program to run.  Command line
arguments are supported, except for wildcard expansion and I/O
redirection (@pxref{Arguments}).

To start @code{gdbserver} without supplying an initial command to run
or process ID to attach, use the @option{--multi} command line option.
Then you can connect using @code{target extended-remote} and start
the program you want to debug.

@code{gdbserver} does not automatically exit in multi-process mode.
You can terminate it by using @code{monitor exit}
(@pxref{Monitor Commands for gdbserver}).


@item set remote exec-file @var{filename}
@itemx show remote exec-file
@anchor{set remote exec-file}
@cindex executable file, for remote target
Select the file used for @code{run} with @code{target
extended-remote}.  This should be set to a filename valid on the
target system.  If it is not set, the target will use a default
filename (e.g.@: the last program run).


And here's the new packets:

@item vAttach;@var{pid}
@cindex @samp{vAttach} packet
Attach to a new process with the specified process ID.  @var{pid} is a
hexadecimal integer identifying the process.  If the stub is currently
controlling a process, it is killed.  The attached process is stopped.

This packet is only available in extended mode.

Reply:
@table @samp
@item E @var{nn}
for an error
@item @r{Any stop packet}
for success (@pxref{Stop Reply Packets})
@end table

@item vRun;@var{filename}@r{[};@var{argument}@r{]}@dots{}
@cindex @samp{vRun} packet
Run the program @var{filename}, passing it each @var{argument} on its
command line.  The file and arguments are hex-encoded strings.  If
@var{filename} is an empty string, the stub may use a default program
(e.g.@: the last program run).  The program is created in the stopped
state.  If the stub is currently controlling a process, it is killed.

This packet is only available in extended mode.

Reply:
@table @samp
@item E @var{nn}
for an error
@item @r{Any stop packet}
for success (@pxref{Stop Reply Packets})
@end table



-- 
Daniel Jacobowitz
CodeSourcery