From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3516 invoked by alias); 7 Aug 2002 22:31:17 -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 3499 invoked from network); 7 Aug 2002 22:31:16 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 7 Aug 2002 22:31:16 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C99D33D93; Wed, 7 Aug 2002 18:31:14 -0400 (EDT) Message-ID: <3D519FB2.6090605@ges.redhat.com> Date: Wed, 07 Aug 2002 15:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: ``detach remote'' References: <20020806210009.GA29965@nevyn.them.org> <3D517576.2070001@ges.redhat.com> <20020807194959.GA1535@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00171.txt.bz2 > 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. Ignoring the implementation, there are a strong architectural grounds for the extended-remote behavour. > 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. The only one that is of concern here is gdb/gdbserver. Given, to enable extended-remote, the user has to type: (gdb) remote extended-remote .... I don't think many people use or know about it. I also suspect that recent changes, such as daemon mode, may have had unexepcted consequences. Unless you hang onto the process and/or add mechanisms for attaching to a new process, daemon mode is pretty useless. The latter would be correct, sounds like the former is what happened :-( >> 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". Ok. >> 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. There are two categories of remote target. - remote board/stub - remote process/server A board is always there, power cycle it, kick it, disconnect it, reconnect to it, and it is still there. GDB is talking to a very raw and very permenant target. The lifetime of the debug agent and the corresponding board are the same (ignoring a few esoteric edge conditions which really fall into remote process). A process is more tempoary. Both the remote connection and the process have lifetimes and their lifetimes are independant. Drop the connection and the process still runs. Kill the process and the connection is still live. Extended-remote was added (I believe) to handle the second case -- a remote process. I think it is a failure to clearly differentiate between thses two cases (and recongnise that the connection and remote process can have different lifetimes) that has lead to the problems we have here. > 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. Er, detach should behave according to its specification vis: (gdb) help detach Detach a process or file previously attached. If a process, it is no longer traced, and it continues its execution. If you were debugging a file, the file is closed and gdb no longer accesses it. In the case of a remote process that should [I think clearly] apply to the process and not the connection. If the intent is to drop the connection, then something like ``target none'' or ``target child''. > 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?) The user enters ``detach'' to disconnect from the process. Who cares if it is local or remote. > For extended-remote (only?), new command "remote attach" > Debug agent attaches to a new program The user enters ``attach PID''. Again, who cares if it is local or remote. -- I think, the easiest way of doing things is to have: target remote FOO negotiate extended-remote. If the target supports it then enable it. Otherwize fall back to primative remote that we see now. enjoy, Andrew