Re: RFA/RFC: vCont for the remote protocol [doco]

[Andrew Cagney <ac131313@redhat.com>]

> 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