cont vs run -- the real deal

cont vs run -- the real deal

[Brendan Kehoe]

Does there exist in writing an explanation of why "run" works for native 
programs and "target sim" targets, but "cont" is the correct approach 
for "target remote ..." ?  The docs I'm able to see, and the sources for 
the various stubs and infcmd.c all seem to leave it implied somehow.

Thanks,
B

Re: cont vs run -- the real deal

[Paul Koning]

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

     paul

Re: cont vs run -- the real deal

[Daniel Jacobowitz]

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