The packet exchange for the GDB continue is very similar to that for the step (see Section 3.2.6). The difference is that in the absence of a breakpoint, the target program may complete execution. A simple implementation need not trap the exit—GDB will handle the loss of connection quite cleanly.

The RSP packet exchanges to implement the GDB continue command are shown as a sequence diagram in Figure 3.6. In this example the target executes to completion and exits, without returning a reply packet to the GDB client.

Figure 3.6.  RSP packet exchanges for the GDB continue command

The packet exchange is initially the same as that for a GDB step or stepi command (see Figure 3.4).

In this example the gdbarch_single_step_through_delay () function finds that the previously executed instruction is a jump instruction (m packet). Since the target may be in a delay slot, it executes a single step (s packet) to step past that slot, followed by notification of the TRAP exception (S05 packet) and register cache reload (g packet).

The next call to gdbarch_single_step_through_delay () determines that the previous instruction did not have a delay slot (m packet), so the c packet can be used to resume execution of the target.

Since the target exits, there is no reply to the GDB client. However it correctly interprets the loss of connection to the server as target execution. Through this exchange, the GDB client shows the following output:

(gdb) continue
Continuing.
Remote connection closed
(gdb)