Re: RFC: ``detach remote''

[Daniel Jacobowitz <drow@mvista.com>]

More later, but:

On Sun, Aug 11, 2002 at 02:02:09PM -0400, Andrew Cagney wrote:
> (top-gdb) target core
> No core file specified.  (Use `detach' to stop debugging a core file.)

... which uses detach for its current meaning of `disconnect' rather
than the `process detach' we're now saying would be better.

> > 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

And it's not clear what close/continue would mean in some cases, e.g.
gdbserver; does the target still stop on events?

> 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>

Sure.

> >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.

Not sure what you mean to say here.  I want a way to close the
connection opened by "target", non-destructively, however.

> >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.

The think is, now it uses kill.  Kill would not close the agent
session, which is obviously not the desired behavior.  If you want it
to kill the agent (I think this is reasonable!) then there needs to be
a command for it other than the ``monitor'' odds-and-ends command, so
that extended-remote targets will have some obligation to know what to
do when they receive the kill message.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer