The final sequence shows the behavior when execution is resumed after a breakpoint with the continue command. Figure 2.12 shows the high level sequence diagram for GDB in response to the continue command. This sequence shows the behavior for the first call to continue after a run stopped due to a breakpoint.
The command functionality is provided by the
continue_command
, which calls the
proceed
function for much of its behavior.
proceed
calls the
to_resume
function of the current target to
resume execution. For this first call, the breakpoint(s) removed
when execution completed after the run command
are not replaced and the target resumption is
only for a single instruction step. This allows the target to be
stepped past the breakpoint without triggering an exception.
proceed
then uses
wait_for_inferior
to wait for control to return
after the single step and diagnose the next action. Waiting uses the
to_wait
function of the current target, then
calls handle_inferior_event
to analyze the
result. In this case, handle_inferior_event
determines that a target has just stepped past a breakpoint. It
reinserts the breakpoints and calls the target
to_resume
function again, this time to run
continuously.
wait_for_inferior
will use the current target
to_wait
function again to wait for the target
to stop executing, then again call the
handle_inferior_event
to process the
result. This time, control should return to GDB, so breakpoints
are removed, and handle_inferior_event
and
wait_for_inferior
return. proceed
calls
normal_stop
to tidy up and print out a message
about the current stack frame location where execution has stopped
(see Section 2.11.5.).
It is useful to examine the behavior of the first call to
handle_inferior_event
, to see the sequence for
completing the single step and resuming continuous execution. Figure 2.13 shows the sequence
diagram for the first call to
handle_inferior_event
.
Figure 2.13.
Sequence diagram for the GDB
handle_inferior_event
function after single
stepping an instruction for the continue
command
handle_inferior_event
first determines if a
watchpoint has now been triggered. If this is not the case, it
checks if the processor is now in the delay slot of an instruction
(requiring another single-step immediately). Having determined that
continuous execution is appropriate, it calls the function
keep_going
to reinsert active breakpoints
(using the to_insert_breakpoint
function of the
current target). Finally it calls the to_resume
function of the current target without the single-step
flag set to resume continuous execution.