This is the mail archive of the
mailing list for the GDB project.
Re: cont vs run -- the real deal
On Thu, Jul 06, 2006 at 12:34:37PM -0400, Paul Koning wrote:
> >>>>> "Brendan" == Brendan Kehoe <firstname.lastname@example.org> writes:
> Brendan> Does there exist in writing an explanation of why "run"
> Brendan> works for native programs and "target sim" targets, but
> Brendan> "cont" is the correct approach for "target remote ..." ?
> Brendan> The docs I'm able to see, and the sources for the various
> Brendan> stubs and infcmd.c all seem to leave it implied somehow.
> With remote targets, you're connecting GDB to a program that has
> already been started (by some other means, done at the remote end).
> So you're gaining control afterwards, which means that you're going to
> continue from where it left off.
> The gdbserver case is a bit confusing: when you start an application
> via gdbserver, you're getting control on the first instruction. But
> it's still "after" the run, though well before main().
Yes, this is a fairly accurate description.
This is how I've been thinking about it recently: when you connect to
"target child" (native), or "target sim", there's a concept of "nothing
is running now, start something". When you connect to "target remote",
there isn't such a concept. You're connected to a physical piece of
hardware and you're looking at its physical registers; they're always
I've been sketching a remote protocol extension, like the existing
extended-remote target but much more complete, which would allow a
remote connection to work along with this model. In that case, you can
be connected to a remote target but have nothing running, and even
cause the remote stub to attach to something else running on its end of
I'll post more about that in a week or three, once I have a chance to
sketch out the usage model a bit better; I've already implemented this
but I'm not entirely happy with how, and I have another project to post
about first (file transfer is next, I think).