Re: Multiple process support in gdbserver

[Michael Snyder <msnyder@specifix.com>]

Does this mean support for follow-fork?

On Fri, 2007-12-07 at 16:00 -0500, Daniel Jacobowitz wrote:
> (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
> 
> 
>