This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Proposed remote protocol addition: vCont
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 8 Oct 2003 15:32:19 -0400
- Subject: Re: Proposed remote protocol addition: vCont
- References: <20031001144140.GA4407@nevyn.them.org>
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