Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

2.11.7.  The GDB continue Command after a Breakpoint

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.

High level sequence diagram for the GDB continue command after a breakpoint

Figure 2.12.  High level sequence diagram for the GDB continue command after 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.

Sequence diagram for the GDB handle_inferior_event function after single stepping an instruction for the continue command

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.

Embecosm divider strip