From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20586 invoked by alias); 11 Aug 2002 16:35:09 -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 20579 invoked from network); 11 Aug 2002 16:35:08 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 11 Aug 2002 16:35:08 -0000 Received: from dsl093-061-169.pit1.dsl.speakeasy.net ([66.93.61.169] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17dvgE-00069R-00; Sun, 11 Aug 2002 11:35:02 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17dvgR-0003y0-00; Sun, 11 Aug 2002 12:35:15 -0400 Date: Sun, 11 Aug 2002 09:35:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: ``detach remote'' Message-ID: <20020811163515.GA14609@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com 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> <3D567F7B.7080502@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D567F7B.7080502@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00248.txt.bz2 On Sun, Aug 11, 2002 at 11:15:07AM -0400, Andrew Cagney wrote: > >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? Yeah. It's certainly not universal, though... > >>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 And pipe support for target remote, and an agent which can communicate over said pipe. Neither terribly hard... > >>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''. It doesn't work, anyway: (gdb) target core core A program is being debugged already. Kill it? (y or n) I think that if you really want this to work, you need to have target instances; so that saying "target core" creates a new instance of a core target and you can control instances individually. This is a long way away and it isn't a goal I'm terribly interested in implementing. > >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. No, noting above, there might someday be multiple active targets. We're not there yet. > Need to look at a table to see what operations are possible and then > figure out which map onto commands. Tables and lists, I can do that! Let's see what we've got. I'll pick a sampling of targets and operations. Start with native debugging. The basic things one wants are: - "run": create a new process. - "attach": Attach to a running process. - "detach": Detach from the current process. Let it run. - "kill": End the current process. I think we agree that the current meanings of these commands are right, yes? Then consider remote debugging of a simple ROM monitor. All four of the above commands are meaningless. Currently, the only one of them with meaning is "detach", which sends a D packet and disconnects. The ROM monitor can choose to remain stopped (most do, from what I've seen) or resume when it sees the D packet. It would be nice to have the choice; I think that detach vs. disconnect is a reasonable way to represent this. Protocol side to be determined. Perhaps disconnect would send no packet at all, just close the connection? I think that would work. But I digress. Also, some ROM monitors might support "restart", which currently gets lumped in with "run", but I believe should be a special monitor command instead. That might vary. Then consider a simulator, linked in. - "run" means to restart the simulator - "kill" means to end the simulation - attach and detach have no apparent meaning - disconnect appears to have no useful meaning Then consider a simulator, speaking a remote protocol, whichever remote protocol it may be (I hypothesize that it should be extended-remote and should reject some commands as inappropriate): - run/kill/attach/detach as above - disconnect now has meaning as with the ROM monitor Now let's consider our friend the hypothetical all-singing all-dancing remote process agent. I think we've concluded that we want "run"/"kill"/"attach"/"detach" to behave as with native debugging. We also need a couple of other commands: - Disconnect from the agent, leaving it in its current state, waiting for a new client - Terminate the agent Terminating the agent can be a monitor command. I like the idea of a "disconnect" command. One other thorny issue becomes what to do when the user quits or closes the remote target etc. Right now GDB offers the "kill" prompt as I showed above. For extended-remote that doesn't make a lot of sense to me... I think that either "disconnect" or a "kill"/"terminate" sequence makes more sense. Thoughts? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer