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

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Sep 30, 2003 at 10:37:53AM -0400, Andrew Cagney wrote:
> >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 :-(

That loses the requirement that the default action be last, which I'd
like to hold on to - OK?

I dislike the ';' because vCont is not an item in the list of actions
that the semicolons are separating; that turns ';' from a separator
into a prefix.  But hey, prefixes are people too.

> >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.

OK.

> >>>+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.

All right.  I now remember having this conversation before; witness the
other half of the original thread, with new-thread notifications.  I
don't really see the problem but I'm fine simplifying it.

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

I'd prefer E..; vCont; resumes nothing, and generates no new stops.

> Here's something out of left field:
> 
> 	-> vCont?
> 	<- { "s" | "c" | "P" | "E" | ... }  OR  ""
> 
> that is,  it returns a list of supported letters.

Ooh, I like it, I like it.  Allow both ? and ; as terminators, require
any stub which implements vCont; to also implement vCont?, and there
goes the probing problem.  Then the rest of it falls out.

Let me polish that up and test it and I'll send out an update.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer