target remote-attach?

target remote-attach?

[Michael Snyder]

Just thinking aloud... we ought to have a sort of "remote-attach"
command, that would allow us to connect to a remote target when it
is already in a "run" state.  Right now the initial handshake 
protocol prevents doing that.

The target might be waiting to tell gdb "I stopped because of
a SIGTRAP", or similar, or it might actually be running, and
need to be stopped via a serial BRK or the like.  After that, 
we would be in a sane state from which we could do the usual
remote_open handshake.

Or is there something like that already?

Re: target remote-attach?

[Paul Koning]

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

	   paul

Re: target remote-attach?

[Michael Snyder]

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.

Re: target remote-attach?

[Daniel Jacobowitz]

On Fri, Feb 29, 2008 at 12:14:51PM -0800, Michael Snyder wrote:
> Just thinking aloud... we ought to have a sort of "remote-attach"
> command, that would allow us to connect to a remote target when it
> is already in a "run" state.  Right now the initial handshake 
> protocol prevents doing that.
> 
> The target might be waiting to tell gdb "I stopped because of
> a SIGTRAP", or similar, or it might actually be running, and
> need to be stopped via a serial BRK or the like.  After that, 
> we would be in a sane state from which we could do the usual
> remote_open handshake.
> 
> Or is there something like that already?

It's true that we can't attach to a remote stub where the target is
currently running; we'll be looking at that in the context of non-stop
debugging but probably by changing the remote protocol somewhat.  With
the existing protocol it's hard because sending a query may be
interpreted as an interrupt.  If the stub's waiting to send something,
how's the user supposed to figure out if it already has or not?

-- 
Daniel Jacobowitz
CodeSourcery