From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3265 invoked by alias); 11 Aug 2002 15:15:24 -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 3241 invoked from network); 11 Aug 2002 15:15:16 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 11 Aug 2002 15:15:16 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1A5543C53; Sun, 11 Aug 2002 11:15:08 -0400 (EDT) Message-ID: <3D567F7B.7080502@ges.redhat.com> Date: Sun, 11 Aug 2002 08:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 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> <3D519FB2.6090605@ges.redhat.com> <20020808132512.GA1840@nevyn.them.org> <3D540069.6010203@ges.redhat.com> <20020811030130.GA10208@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00245.txt.bz2 > On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote: > >> >Hold on a second. Gdbserver is in wide use; that may not have been >> >true a couple of years ago, but the reason I've invested so much time >> >in maintaining it is a continually growing customer demand for it. >> >People use this, and they are already used to its behavior. > >> >> [Be careful to separate the interests of the fee paying customer from >> the interests of GDB and the wider GDB community. Fee paying customers >> have an unfortunate habit of being very short sighted :-( :-)] > > > I get more non-customer feedback on gdbserver than customer feedback, > actually. Poor choice of words. I'm told HP once did a study to determine the debug requirements of a typical user. Turns out a typical debug session looks something like: $ ./a.out segmentation fault, core dumped $ gdb ./a.out (gdb) run Program received sig seg 10 a = *b; (gdb) print b $1 b = 0 (gdb) quit ``Advanced users'' get to use up/down and backtrace. Depressing, eh? >> I'm a user, and I'd prefer to be able to type: >> >> (gdb) target remote |ssh machine gdbagent >> (gdb) file foo >> (gdb) run >> Program exited >> >> (gdb) break main >> (gdb) run >> ... >> (gdb) detach >> (gdb) monitor ps >> (gdb) attach >> ..... >> >> instead of: > > > Some day :) Those are nice ideas. It's closer then you might thing. All you need is: - attach packet - detach packet with a correct definition - auto-negotiate of extended-remote >> I think the command sequence would be: >> >> target remote >> attach >> target child -- implicit remote/pid detach >> attach >> >> (Red Herring -- ``target sim'' is equally confused.) > > > The difficulty is what to call "disconnect from the agent". I don't > really like the ambiguity of the target stack here... I suppose adding > a "target none" will suffice, but right now the behavior when unpushing > a running target is to ask the user if they want to kill it. That's > not going to work if we use this as the method to detach and leave the > agent running :) Having "target none" detach and "target child" ask > you if you want to kill doesn't really work either. > > What do you think of letting the target control what happens when > another target is selected? Remote targets could choose to detach. > That's a little better. More background: Looking at the code and recalling comments (some verbal), the original intent was that there could be several active targets. This allows the user to switch between targets: target child a live process target core now look at the core file target child back to that live process I don't know if it works. I've never used it. Turns out that this ideal was corrupted along the way because the implementation only allowed one target of each type. As a consequence, ``target remote'' and ``target sim'' both zap ``target child''. > Or, hey, here's a better idea. A "disconnect" command. Then "target" > can retain its current semantics (kill) and the user will have an > explicit way to disconnect if they want. Hmmm! Noteing the above -- there can be multiple active targets -- therefor there does need to be a way of shutting down a specific target. Presumably ``target none'' would shutdown all of them. Need to look at a table to see what operations are possible and then figure out which map onto commands. enjoy, Andrew