From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2973 invoked by alias); 7 Aug 2002 19:49:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2966 invoked from network); 7 Aug 2002 19:49:45 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 7 Aug 2002 19:49:45 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17cWoR-0005Sy-00; Wed, 07 Aug 2002 14:49:43 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17cWoh-0000Vo-00; Wed, 07 Aug 2002 15:49:59 -0400 Date: Wed, 07 Aug 2002 12:49:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: ``detach remote'' Message-ID: <20020807194959.GA1535@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020806210009.GA29965@nevyn.them.org> <3D517576.2070001@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D517576.2070001@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00170.txt.bz2 On Wed, Aug 07, 2002 at 03:31:02PM -0400, Andrew Cagney wrote: > >So, the GDB manual has this to say about remote debugging: > > > > To resume the remote program and stop debugging it, use the `detach' > > command. > > > >This is not how gdbserver works, and it isn't how any stubs I've worked > >with > >behave, either. They'll sit and wait for a reconnection. Rather than > >change the status quo, I would like to update the documentation and provide > >a way to get the previously documented behavior. This uses the "K" packet > >described in my email to gdb@ last week. The new command is `detach > >remote' > >which I'm not thrilled with but I'm a little short on ideas. It's hard to > >find something to call this. > > > >GDB and gdbserver patches attached. Comments? > > I don't think this is right - either for GDB or for the remote debug > agent. Local or remote, the user should be able to use: > > [attach PID] > detach > > The remote protocol has two modes -- ``remote'' and ``extended-remote''. > In the latter case, GDB doesn't drop the connection -- it assumes that > the remote end will stay around. (Lets ignore my desire to merge the > pair and instead have remote probe the other end for extended-remote > support :-) Hence: I hate extended-remote (current implementation) :) My reasons for hating it have to do with no separation between the local- and remote- commands; in other words, the fact that "kill" doesn't kill the debug agent, etc. Do you know of stubs which use extended-remote? If it's only gdbserver and similar process-level stubs (like maybe the libremote which people keep saying will be released soon?), we have some flexibility with its semantics. > In ``remote'' mode. A detach command should: drop the tcp connection; > set the process free. > > In ``extended-remote'' mode. A detach coommand should: set the process > free. (Lets also ignore that there is no attach mechanism :-). > > That leaves the question of how to implement it using protocol > mechanisms. The ``D'' is messed up, GDB sends the D and then totally > ignores the reply. Actually, it consumes the reply; if it's an Enn packet the detach is aborted. It just doesn't care if the remote acknowledges ("OK") or ignores ("") the "D". > As for remote debug agents, the ones I've used (pretty sure this applied > to gdbserver when I last used it) quit as soon as the connection went > down. An explict daemon mode was required to make them hang around. Let's compare this idea with current reality, for reference: for both Linux (non-i386; i386's is really fancy, and actually resumes on detach, and has interesting process-level-debug hooks. I'm talking about the simpler MIPS and PowerPC stubs) kgdb stubs and gdbserver, which are the only stubs I'm really familiar with, detach causes the connection to close but the process to remain stopped and the debug agent to wait for a reconnection. This is independent of which extended-remote mode we're in. I believe gdbserver's behaved this way for a couple of years at least. I don't like the idea of changing ``detach'' to mean resume. Detach, it seems to me, should be the same as breaking the connection; and resume should have to be explicit. What do you think of this idea, regardless of remote vs extended-remote (which I think should behave consistently in this regard): detach: Close the remote connection, stub waits attach: N/A, this is a local attach new command "remote detach": Debug agent detaches/resumes the program being debugged The agent may or may not hang around (say, remote agents probably don't, extended-remote agents probably do?) For extended-remote (only?), new command "remote attach" Debug agent attaches to a new program -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer