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

[jtc at redback dot com (J.T. Conklin)]

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

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.

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>')?

        --jtc

-- 
J.T. Conklin
RedBack Networks