Re: target remote-attach?

[Michael Snyder <msnyder@specifix.com>]

On Fri, 2008-02-29 at 15:23 -0500, Paul Koning wrote:
> >>>>> "Michael" == Michael Snyder <msnyder@specifix.com> writes:
> 
>  Michael> Just thinking aloud... we ought to have a sort of
>  Michael> "remote-attach" command, that would allow us to connect to a
>  Michael> remote target when it is already in a "run" state.  Right
>  Michael> now the initial handshake protocol prevents doing that.
> 
>  Michael> The target might be waiting to tell gdb "I stopped because
>  Michael> of a SIGTRAP", or similar, or it might actually be running,
>  Michael> and need to be stopped via a serial BRK or the like.  After
>  Michael> that, we would be in a sane state from which we could do the
>  Michael> usual remote_open handshake.
> 
>  Michael> Or is there something like that already?
> 
> I haven't seen the problem you mention.  gdbserver allows attaching to
> a running process (by PID) and that has always worked for me.  For
> that matter, it works also with a native gdb (local debug).
> 
> Similarly, I've used the remote target protocol for kernel debug,
> connecting after the kernel panic handler has invoked the stub via a
> breakpoint instruction.  That too works fine.

Yeah, the situation I have in mind is, say you've already been
connected, and you've said "continue", and then while gdb was
waiting for the target to say "OK, I've stopped", you lost the
connection.  

The situation you mention (native "attach") is kind of analogous.
You want to connect to a running target, possibly interrupt it, 
(native attach sends the child a signal), and then handshake.