From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12042 invoked by alias); 11 Aug 2002 18:02:14 -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 12035 invoked from network); 11 Aug 2002 18:02:12 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 11 Aug 2002 18:02:12 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DFDCB3C53; Sun, 11 Aug 2002 14:02:09 -0400 (EDT) Message-ID: <3D56A6A1.7040904@ges.redhat.com> Date: Sun, 11 Aug 2002 11:02: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> <3D567F7B.7080502@ges.redhat.com> <20020811163515.GA14609@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00253.txt.bz2 > On Sun, Aug 11, 2002 at 11:15:07AM -0400, Andrew Cagney wrote: > 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. I'm sure it did work. Hmm, I can create this: (gdb) Program received signal SIGINT, Interrupt. 0x41cd3a98 in ?? () from /usr/lib/libc.so.12 (top-gdb) print target_stack->target_ops->to_longname $17 = 0x1b0a040 "Unix child process" (top-gdb) print target_stack->next->target_ops->to_longname $18 = 0x1b09840 "Local core dump file" (top-gdb) print target_stack->next->next->target_ops->to_longname $19 = 0x1af87e4 "Local exec file" (top-gdb) print target_stack->next->next->next->target_ops->to_longname $20 = 0x1af5530 "None" Oh, well. >> >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. We've an active core file and unix child. Just can't get back to the core file. Btw, check this message: (top-gdb) target core No core file specified. (Use `detach' to stop debugging a core file.) >> 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? For target the comment reads: (top-gdb) help target Connect to a target machine or process. The first argument is the type or protocol of the target machine. Remaining arguments are interpreted by the target protocol. For more information on the arguments for a particular protocol, type `help target ' followed by the protocol name. Note the use of the words ``protocol'' and ``machine''. I.e. ``target ...'' establishes a physical connection. > 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. When GDB attaches to a remote target, there is similar confusion. Its assumed that there is already a remote program and it has stopped. ``remote cisco'' assumes that the target is still running, you need to interrupt it. > 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. So the possible transactions: close connection options: kill, detach, continue, none open connection initial state: stopped, dead, running detach kill attach start continue I think an existing simple remote target either: close / continue - target allowed to run but not detached close / none - target still attached but not resumed ``restart'' is something of a peverted form of run/continue. The program eventually stops again. Another way of handling it is: (gdb) monitor restart -> qRcmd ``restart'' <- T > 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 See include/gdb/remote-sim.h. The PPC simulator can live in either the remote, or the extended-remote world. It is somewhat unique in this regard. Other simulators live in the pure remote world -- it is trying to mimic an embedded board. Stan Shebs and I had a very long debate (many many years ago) about what the sim model in GDB should be. The status-quo, modeling a bare board (Stan), has so far prevailed. > 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. Either a monitor command or an agent option. Exit on disconnect. > 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? The sequence is: (gdb) attach 20856 Attaching to program: /home/scratch/GDB/native/gdb/gdb, process 20856 0x41b44a04 in ?? () (gdb) target core gdb.core A program is being debugged already. Kill it? (y or n) In certain situtations, yes that message doesn't make sense. The default [y] should still be to do something pretty fatal though. Perhaphs suggest ``detaching'' first. Andrew