Re: cont vs run -- the real deal

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 06, 2006 at 12:34:37PM -0400, Paul Koning wrote:
> >>>>> "Brendan" == Brendan Kehoe <brendan@zen.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
there.

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
the wire.

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

-- 
Daniel Jacobowitz
CodeSourcery