====== command vCont ======

**Format:** ‘vCont[;action[:thread-id]]…’

**Meaning:** Resume the inferior, specifying different actions for each thread.

For each inferior thread, the leftmost action with a matching thread-id is applied. Threads that don’t match any action remain in their current state. Thread IDs are specified using the syntax described in thread-id syntax. If multiprocess extensions (see multiprocess extensions) are supported, actions can be specified to match all threads in a process by using the ‘ppid.-1’ form of the thread-id. An action with no thread-id matches all threads. Specifying no actions is an error.

Currently supported actions are:

  * ‘c’        Continue. 
  * ‘C sig’    Continue with signal sig. The signal sig should be two hex digits. 
  * ‘s’        Step. 
  * ‘S sig’    Step with signal sig. The signal sig should be two hex digits. 
  * ‘t’        Stop. 
  * ‘r start,end’    Step once, and then keep stepping as long as the thread stops at addresses between start (inclusive) and end (exclusive). The remote stub reports a stop reply when either the thread goes out of the range or is stopped due to an unrelated reason, such as hitting a breakpoint. See range stepping.

If the range is empty (start == end), then the action becomes equivalent to the ‘s’ action. In other words, single-step once, and report the stop (even if the stepped instruction jumps to start).

(A stop reply may be sent at any point even if the PC is still within the stepping range; for example, it is valid to implement this packet in a degenerate way as a single instruction step operation.)

The optional argument addr normally associated with the ‘c’, ‘C’, ‘s’, and ‘S’ packets is not supported in ‘vCont’.

The ‘t’ action is only relevant in non-stop mode and may be ignored by the stub otherwise. A stop reply should be generated for any affected thread not already stopped. When a thread is stopped by means of a ‘t’ action, the corresponding stop reply should indicate that the thread has stopped with signal ‘0’, regardless of whether the target uses some other signal as an implementation detail.

The server must ignore ‘c’, ‘C’, ‘s’, ‘S’, and ‘r’ actions for threads that are already running. Conversely, the server must ignore ‘t’ actions for threads that are already stopped.

Note: In non-stop mode, a thread is considered running until GDB acknowledges an asynchronous stop notification for it with the ‘vStopped’ packet.

The stub must support ‘vCont’ if it reports support for multiprocess extensions.