RFC: ``detach remote''

[Andrew Cagney]

> 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