Multiple process support in gdbserver

Multiple process support in gdbserver

[Daniel Jacobowitz]

(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

Re: Multiple process support in gdbserver

[Michael Snyder]

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

Re: Multiple process support in gdbserver

[Daniel Jacobowitz]

On Mon, Dec 10, 2007 at 09:00:31AM -0800, Michael Snyder wrote:
> Does this mean support for follow-fork?

No, only what I described in that message (run, attach, re-run).
follow-fork and multiple forks would be a separate project.

I'm slightly regretting calling it "multi-process" since that means at
least three completely different things.

-- 
Daniel Jacobowitz
CodeSourcery