Remote protocol extension - detaching

Remote protocol extension - detaching

[Daniel Jacobowitz]

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?

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

Re: Remote protocol extension - detaching

[William A. Gatliff]

... or how about just adding some arguments to the detach packet?

b.g.

On Wed, Jul 31, 2002 at 02:37:02PM -0400, Daniel Jacobowitz 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?
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Remote protocol extension - detaching

[Daniel Jacobowitz]

I'm not sure whether we can do that in a backwards-compatible way with
existing stubs.  It's a good idea, though - I like it :)

On Wed, Jul 31, 2002 at 02:19:40PM -0500, William A. Gatliff wrote:
> ... or how about just adding some arguments to the detach packet?
> 
> b.g.
> 
> On Wed, Jul 31, 2002 at 02:37:02PM -0400, Daniel Jacobowitz 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?
> > 
> > -- 
> > Daniel Jacobowitz                           Carnegie Mellon University
> > MontaVista Software                         Debian GNU/Linux Developer
> 
> -- 
> Bill Gatliff
> bgat@billgatliff.com
> 

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

Re: Remote protocol extension - detaching

[Andrew Cagney]

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

Andrew

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

Re: Remote protocol extension - detaching

[Daniel Jacobowitz]

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