target remote-attach?

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?

>>>>> "Michael" == Michael Snyder
<msnyderspecifix.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

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

On Fri, 2008-02-29 at 15:23 -0500, Paul Koning wrote:
> >>>>> "Michael" == Michael
Snyder <msnyderspecifix.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.