Re: [RFC]: Remote Protocol "attach" command.

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> Michael> More and more embedded operating systems are multi-process
> Michael> these days, and so there exists a need to have a stub or a
> Michael> gdbserver already running (perhaps all the time), and have it
> Michael> "attach" to another running process and debug it.  For native
> Michael> Unix systems, this has traditionally been done by running
> Michael> gdbserver from a shell, giving it the path to the executable,
> Michael> and letting it fork the new process.
> 
> Michael> I'd like to start a discussion about adding a new remote
> Michael> protocol command with which GDB could ask the remote stub
> Michael> to attach to a running process (by pid), or possibly to
> Michael> open a file and fork a process (by filename/path).  Of course,
> Michael> stubs that can't do that would simply return an empty reply
> Michael> as always, indicating non-compliance.
> 
> I'm not opposed to this, although there appear to be some issues to be
> worked out.
> 
> At present, when `target remote <foo>' is issued, GDB attaches to and
> stops the target, possibly getting thread and section relocation info
> in the process.  It would be easier if the `target remote <foo>' only
> established communication to a target, and that a separate 'run' or
> 'attach' command needed to be issued to interact.  This model works
> quite well, I use it in my vxWorks/WDB back end.  But I can't see how
> it can be retrofited into the remote protocol.  It pretty much assumes
> an interrupt driven debug agent that can handle async commands without
> disturbing the target system.  I'm afraid I have more questions than
> answers here.

The CISCO version of the protocol is kind of like this.  For CISCO, when
you do an attach it assumes that the target is running and doesn't
attempt any extra magic configury (for instance try to send a ``!'' or
``qOffsets''). For what it is worth, CISCO did this (and a few other
things) right.

A second thing to note is that at present the target vector scrambles
the semantics of target_open() and
target_attach()/target_create_inferior() (and a few others).  The TODO
file tries to make comments on this.

As for retro fitting something, hmm.

> For the command itself, I think it probably should be defined as a
> some command letter plus an 'target specific' identifier.  On UNIX
> like systems, process-ids are natural.  But on others, a process or
> task name may be more appropriate.

Yes, I think that the ``id'' should be a hex encoded string.  On unix
the string would be textual representation of the process ID.  On other
systems, well who knows.

The other gaping whole would be a ``run'' / restart packet that allowed
you to specify a program.

> As you know, the remote debug protocol has not supported well defined
> error codes.  A failure would return EXX, but there was no definition
> of the different XX values.  I think that all new commands should do
> so.  I'm kicking myself for not doing so when I proposed the breakpoint
> extensions a year+ ago.
> 
> There already is a detach command.  I think the protocol spec could be
> worded to indicate that the program under debug is released to
> continue executing.  It does not appear that gdbserver understands the
> command.  Question: after the inferior is detached, should you be able
> to re-attach (or attach to a different process) without
> re-establishing communication to the debug agent (with `target remote
> <foo>')?

That detatch command is something else again.  I think it is wrong /
broken.  The rationale is similar to why the set-baud packet was broken.

GDB sends the ``detatch'' packet just before the connection is dropped. 
This allows something haning of a semi-permenant serial connection (ie
serial port) to be notified of GDB's pending departure.   What should
happen is that the transport layer should shut its self down.  The
detatch packet scrambles protocol layers :-(

	Andrew