Re: Remote protocol extension - detaching

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Aug 04, 2002 at 02:20:24PM -0400, Andrew Cagney wrote:
> >Right now, the standard behavior for a stub on detach is to wait for the
> >client to reconnect.  It would be convenient to have the normal local
> >execution behavior available, also: that is, on detach, resume the
> >application.  This could be done with or without leaving the stub running.
> >
> >I'd like to commandeer the 'K' packet for this; 'd' and 'D' are already
> >taken.  Anyone have a better suggestion?
> 
> ``detach'' could mean too many things here.
> 
> - There is GDB detaches from the remote target -- it shuts down the tcp 
> connection.
> 
> - There is the remote debug agent detaching from the process being debugged.
> 
> I'm also wondering how this relates to GDB's target stack and command set.

Yeah.  I'm not terribly fond of the overloading of "detach".  Worse,
the only thing I could think of was either "set remote detach on" or
"detach -detach", and those are pretty silly.  Better suggestions
anyone?  Please?

After thinking about William Gatliff's comment, I think 'K' should
serve as an alternate to the 'D' GDB already sends, indicating that
the connection will be closed in a moment and the child should be
resumed (when that happens?).

> Andrew
> 
> (k makes me think of kill, but d is taken ...)

Yeah.  I used K because it (could) kill the stub - it would cause
gdbserver to exit, probably, because gdbserver isn't set up to process
events with no GDB.  Although I could make it do so pretty easily, I
suppose, and that might be more useful... hack, hack...

This would also be useful for kgdb; right now to get this effect you
have to disable all breakpoints, continue, and kill GDB.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer