This is the mail archive of the
mailing list for the GDB project.
Re: target remote-attach?
- From: Paul Koning <Paul_Koning at dell dot com>
- To: msnyder at specifix dot com
- Cc: gdb at sourceware dot org
- Date: Fri, 29 Feb 2008 15:23:03 -0500
- Subject: Re: target remote-attach?
- References: <email@example.com>
>>>>> "Michael" == Michael Snyder <firstname.lastname@example.org> 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.