RFA/RFC: vCont for the remote protocol [doco]
Andrew Cagney
ac131313@redhat.com
Tue Sep 30 14:37:00 GMT 2003
> 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
More information about the Gdb-patches
mailing list