This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA/RFC: vCont for the remote protocol [doco]
On Mon, Sep 29, 2003 at 05:17:44PM -0400, Andrew Cagney wrote:
>-@item @code{v} --- reserved
>+@item @code{v} --- verbose packet prefix
>
>-Reserved for future use.
>+Packets starting with @code{v} are identified by a multi-letter name,
>+up to the first @code{:} if any.
... first non-alpabetic character, if any. Unless you want to pin down
the terminator?
I think ";" will work better as, in the below, it better separates out
the separate actions.
I meant to pin down the terminator. If you want a ';' then that's OK
by me, I can update the patch to use a semicolon. Makes sense, but the
colon felt more natural.
I agree that ":" _feels_ more natural, it just goes against the rest of
the packet where ";", and not ":" is the separator. It lets the packet
be specified as:
packet ->> "vCont" { field }+
field ->> ";" action [ ":" tid ]
which is very easy to parse. BTW, intro has this to say, so there
aren't any guidelines :-(
Fields within the packet should be separated using @samp{,} @samp{;} or
@cindex remote protocol, field separator
@samp{:}. Except where otherwise noted all numbers are represented in
@sc{hex} with leading zeros suppressed.
Implementors should note that prior to @value{GDBN} 5.0, the character
@samp{:} could not appear as the third character in a packet (as it
would potentially conflict with the @var{sequence-id}).
>+@item
>@code{vCont:}[@var{action}@code{:}@var{tid}@code{;}]...[@var{action}] ---
>extended resume
>+@cindex @code{vCont} packet
>+
>+Resume the inferior. Different actions may be specified for each thread.
>+If a final action is specified, then it is applied to all threads not
>+explicitly mentioned; if no final action is specified, all other threads
>+should remain stopped. Possible actions are @code{s}, @code{S}@var{sig},
>+@code{c}, and @code{C}@var{sig}, with the same meanings as those packets.
>+The final @var{addr} associated with those packets is not supported in
>+@code{vCont}. Thread IDs are specified in hexadecimal.
Suggest a table.
>+First reply:
>+@table @samp
>+@item OK
No.
The behavior shall be identical to the other continuation packets. If
it isn't recognized, "" is returned.
I did this in parallel to 'E'. Yes, I realize that 'E' has problems,
but I really think this isn't one of them; it keeps the client code a
whole lot simpler, since we don't have to detect and handle a failed
vcont in the main loop. We can fall back immediately to sending a 'c'
packet or whatever. It also lets us retry using 'C' for free.
Also, the ability to differentiate between "stub does not support
vcont" and "this vcont was illegal" seems useful to me - for debugging
purposes if nothing else. Or if some stub supports step-out-of-range
in a vcont packet (I think that would be a bad idea; call it vCont2
instead and avoid the issue).
Why do you prefer not doing this?
It runs completly against the remote protocol's RPC model: one request,
one response.
The transaction contains extra states, while those states add to the
transactions complexity, they do it without adding any real value:
It adds unnecessary latency (due to additional round trips) to the
transaction. Remember this really involves:
-> vCont;....
<- +
<- OK
-> +
<- T00....
-> +
when just:
-> vCont;...
<- +
<- T00
-> +
is all that is needed.
When async, having fewer states makes the state machine logic easier.
You may find it useful to clarify the spec so that a separate probe is
possible vis
-> vCont
<- Enn or OK or Tnn?
|| -> vCont
<-
speaking of which. What happens if vCont specifies nothing? Return a
dummy Tnn packet? Return OK?
Implementation currently returns ""; it only recognizes vCont with the
colon.
What does:
vCont;
return then then? I think "T00" would make sense - target stopped,
nothing interesting happened. The other would be "E..".
Here's something out of left field:
-> vCont?
<- { "s" | "c" | "P" | "E" | ... } OR ""
that is, it returns a list of supported letters.
Andrew