From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24373 invoked by alias); 10 Dec 2007 17:16:05 -0000 Received: (qmail 24302 invoked by uid 22791); 10 Dec 2007 17:16:04 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Dec 2007 17:15:59 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id B9AFF3C1B4; Mon, 10 Dec 2007 09:15:56 -0800 (PST) Subject: Re: Multiple process support in gdbserver From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20071207210028.GA32256@caradoc.them.org> References: <20071207210028.GA32256@caradoc.them.org> Content-Type: text/plain Date: Mon, 10 Dec 2007 17:16:00 -0000 Message-Id: <1197306031.32169.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit 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/msg00068.txt.bz2 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 > > >