This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: ``detach remote''
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<stop packet>
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