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

[Daniel Jacobowitz <drow@mvista.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.

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

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

> 
> >+for success
> >+@item E@var{NN}
> >+for an error
> >+@end table
> >+
> >+If the first reply is @samp{OK}, then the inferior will be resumed, and
> >+another reply sent when it stops.  @xref{Stop Reply Packets}, for the 
> >reply
> >+specifications.
> 
> Andrew
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer