The RSP offers two mechanisms for stepping and continuing programs. The original mechanism has the thread concerned specified with a Hc packet, and then the thread stepped or continued with a s, S, c or C packet.

The newer mechanism uses the vCont: packet to specify the command and the thread ID in a single packet. The availability of the vCont: packet is established using the vCont? packet.

The simplest GDB execution command is the stepi command to step the target a single machine instruction. The RSP packet exchanges to implement the GDB stepi command are shown as a sequence diagram in Figure 3.4. In this example the instruction at address 0x100 is executed.

Figure 3.4.  RSP packet exchanges for the GDB stepi command

The first exchange is related to the definition of the architecture used in this example. Before stepping any instruction, GDB needs to know if there is any special behavior due to this instruction occupying a delay slot. This is achieved by calling the gdbarch_single_step_through_delay () function. In this example, that function reads the instruction at the previous program counter (in this case address 0x0) to see if it was an instruction with a delay slot. This is achieved by using the m packet to obtain the 4 bytes of instruction at that address.

The next packet, vCont? from the client seeks to establish if the server supports the vCont packet. A null response indicates that it is not.

	Note
	The vCont? packet is used only once, and the result cached by the GDB client. Subsequent step or continue commands will not result in this packet being reissued.

The client then establishes the thread to be used for the step with the Hc0 packet. The value 0 indicates that any thread may be used by the server.

	Note
	Note the difference to the earlier use of the Hc packet (see Section 3.2.1), where a value of -1 was used to mean all threads.

	Note
	The GDB client remembers the thread currently in use. It does not issue further Hc packets unless the thread has to change.

The actual step is invoked by the s packet. This does not return a result to the GDB client until it has completed. The reply indicates that the server stopped for signal 5 (TRAP exception).

	Caution
	In the RSP, the s packet indicates stepping of a single machine instruction, not a high level statement. In this way it maps to GDB's stepi command, not its step command (which confusingly can be abbreviated to just s).

The last two exchanges are a g and m packet. These allow GDB to reload its register cache and note the instruction just executed.

Through this exchange, the GDB client shows the following output:

(gdb) stepi
0x00000104 in _start ()
(gdb)