The v packets provide additional flexibility in controlling execution on the target. Much of this is related to non-stop targets with multithreading support and to flash memory control and need not be supported in a simple implementation.
All the v packet functionality is provided in the
function rsp_vpkt ()
.
The vAttach and vRun packets are only required for extended remote debugging.
vRun is used to specify a new program to be run, or if no program is specified that the existing target program be run again. In the current implementation, only this latter option is supported. Any program specified is ignored with a warning. The semantics of the vRun command are that the target is left in the stopped state, and the stopped condition reported back to the client.
The vRun packet may also specify arguments to pass to the program to be run. In the current implementation those arguments are ignored with a warning.
This behavior is identical to that of the R (restart) packet (see Section 4.7.11) with the addition of a reply packet. The implementation uses exactly this functionality, with a reply packet reporting a TRAP exception.
rsp_restart (); put_str_packet ("S05");
The vAttach packet allows a client to attach to
a new process. In this target, there is only one process, so the
process argument is ignored and no action taken. However a stop
response is required, so a reply packet indicating a TRAP
exception is sent
(put_str_packet ("S05")
.
The vCont packet provides a more fine grained control over individual threads than the c or s packets.
Support for vCont packets is established with a vCont? packet which should always be supported. In the current implementation, vCont is not supported, so an empty response is provided to any vCont? packet.
The vFile packet allows a file operation to be implemented on a target platform. In the absence of any file system with the "bare metal" target, this packet is not supported. An empty response is sent and a warning printed.