vCont request

vCont request

[Eli Zaretskii]

Can someone please tell me what is the advantage of using the vCont
request in the remote protocol?

From reading the sources, I see that remote.c:remote_resume uses an
alternative method via the `c' or `s' packets, but it isn't clear why
vCont is preferred.  From various hints in the manual I vaguely
understand that this involves resuming different threads with
different conditions/signals, but the details are sketchy at best.  In
particular, what GDB user-level commands are affected by availability
of vCont?

I need this information to clarify the relevant manual sections.

TIA

Re: vCont request

[Daniel Jacobowitz]

On Sat, Apr 09, 2005 at 02:23:55PM +0300, Eli Zaretskii wrote:
> Can someone please tell me what is the advantage of using the vCont
> request in the remote protocol?
> 
> >From reading the sources, I see that remote.c:remote_resume uses an
> alternative method via the `c' or `s' packets, but it isn't clear why
> vCont is preferred.  From various hints in the manual I vaguely
> understand that this involves resuming different threads with
> different conditions/signals, but the details are sketchy at best.  In
> particular, what GDB user-level commands are affected by availability
> of vCont?
> 
> I need this information to clarify the relevant manual sections.

That's right - it's about thread support, both for the existing
commands we have and some others that have been tossed about but never
implemented.  I apologize if it's unclear; I wrote that entry.

The original way to control individual threads was to set the thread
number using 'Hc', and then continue using one of the [CcSs] packets.
Hc has options of "a specific thread", "all threads", or "any thread".

This is only a small set of the possible resume actions; vCont is more
thorough.  One example of existing commands that could not be handled
well by the old method is "set scheduler-locking" - in fact, its
default setting, which is off - in combination with "thread".  With
scheduler locking off, the "step" command means "step this thread, but
allow other threads to run freely while we do it".  With it on, "step"
means "step only the current thread".  HcTID followed by s means the
latter - we use this to step over a removed breakpoint.  There's no
clear way to send a step request which affects a particular thread, so
the remote stub has to guess.  Normally it guesses the last thread to
run; normally that's right.  Very frustrating when it's wrong.

Another example that can be described by vCont but not by the existing
commands is pausing a specific thread; there's no GDB interface for
this today, but it's a reasonably intuitive operation.  vCont can say
"please continue this specific set of threads only".

It's also marginally more efficient.  A major bottleneck in the remote
protocol is latency rather than bandwidth; we only have to ack one
packet instead of two.  And it reduces the statefulness of the
protocol.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: vCont request

[Eli Zaretskii]

> Date: Sat, 9 Apr 2005 09:35:41 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> That's right - it's about thread support, both for the existing
> commands we have and some others that have been tossed about but never
> implemented.  I apologize if it's unclear; I wrote that entry.

The documentation of vCont request itself is fine; it's its effect on
user commands that was unclear, since the functionalities of vCont and
Hc were described as being roughly equivalent.

Thanks for the explanations, they allowed me to put the appropriate
text in the manual.