From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31586 invoked by alias); 7 Dec 2007 21:00:43 -0000 Received: (qmail 31566 invoked by uid 22791); 7 Dec 2007 21:00:42 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Dec 2007 21:00:34 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 9399A98349 for ; Fri, 7 Dec 2007 21:00:29 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 5A7C1982D9 for ; Fri, 7 Dec 2007 21:00:29 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J0kJA-0000GW-99 for gdb@sourceware.org; Fri, 07 Dec 2007 16:00:28 -0500 Date: Fri, 07 Dec 2007 21:00:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Multiple process support in gdbserver Message-ID: <20071207210028.GA32256@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00062.txt.bz2 (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