Proposed remote protocol addition: vCont

Proposed remote protocol addition: vCont

[Daniel Jacobowitz]

After long discussion, I would like to propose this addition to the remote
protocol.  It specifies a more thread-aware syntax for resuming the
inferior, allowing an arbitrary combination of stepped, signalled, resumed,
and frozen threads.  This does _not_ obsolete the existing c/C/s/S packets;
the parser for this packet is larger than some hand-coded stubs.

Here's the documentation:

`v' -- verbose packet prefix
     Packets starting with `v' are identified by a multi-letter name,
     up to the first `;' or `?' (or the end of the packet).

`vCont'[;ACTION[`:'TID]]... -- extended resume
     Resume the inferior.  Different actions may be specified for each
     thread.  If an action is specified with no TID, then it is applied
     to any threads that don't have a specific action specified; if no
     default action is specified than other threads should remain
     stopped.  Specifyin multiple default actions is an error;
     specifying no actions is also an error.  Thread IDs are specified
     in hexadecimal.  Currently supported actions are:
 
    `c'
          Continue
 
    `CSIG'
          Continue with signal SIG
 
    `s'
          Step
 
    `SSIG'
          Step with signal SIG

     The optional ADDR argument normally associated with these packets
     is not supported in `vCont'.

     Reply: *Note Stop Reply Packets::, for the reply specifications.

`vCont?' -- extended resume query
     Query support for the `vCont' packet.

     Reply:
    ``vCont'[;ACTION]...'
          The `vCont' packet is supported.  Each ACTION is a supported
          command in the `vCont' packet.

    `'
          The `vCont' packet is not supported.



[By the way, I just discovered that the file-IO protocol is not
threading-friendly; but that's an unlikely combination anyway, and not hard
to fix.]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Proposed remote protocol addition: vCont

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 10:41:40AM -0400, Daniel Jacobowitz wrote:
> After long discussion, I would like to propose this addition to the remote
> protocol.  It specifies a more thread-aware syntax for resuming the
> inferior, allowing an arbitrary combination of stepped, signalled, resumed,
> and frozen threads.  This does _not_ obsolete the existing c/C/s/S packets;
> the parser for this packet is larger than some hand-coded stubs.
> 
> Here's the documentation:
> 
> `v' -- verbose packet prefix
>      Packets starting with `v' are identified by a multi-letter name,
>      up to the first `;' or `?' (or the end of the packet).
> 
> `vCont'[;ACTION[`:'TID]]... -- extended resume
>      Resume the inferior.  Different actions may be specified for each
>      thread.  If an action is specified with no TID, then it is applied
>      to any threads that don't have a specific action specified; if no
>      default action is specified than other threads should remain
>      stopped.  Specifyin multiple default actions is an error;
>      specifying no actions is also an error.  Thread IDs are specified
>      in hexadecimal.  Currently supported actions are:
>  
>     `c'
>           Continue
>  
>     `CSIG'
>           Continue with signal SIG
>  
>     `s'
>           Step
>  
>     `SSIG'
>           Step with signal SIG
> 
>      The optional ADDR argument normally associated with these packets
>      is not supported in `vCont'.
> 
>      Reply: *Note Stop Reply Packets::, for the reply specifications.
> 
> `vCont?' -- extended resume query
>      Query support for the `vCont' packet.
> 
>      Reply:
>     ``vCont'[;ACTION]...'
>           The `vCont' packet is supported.  Each ACTION is a supported
>           command in the `vCont' packet.
> 
>     `'
>           The `vCont' packet is not supported.
> 
> 
> 
> [By the way, I just discovered that the file-IO protocol is not
> threading-friendly; but that's an unlikely combination anyway, and not hard
> to fix.]

There were no objections (Jim gave me some helpful minor edits for the
documentation, though).

Andrew, were the remote.c parts of the patch OK now that the protocol
is settled?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer