Breakpoints are marked in the source-level and disassembly-level view in the gray margin, at the left side of the window. Standard software and hardware breakpoints are identified by a disc icon, which is color-coded to reflect the type (see Software and hardware breakpoints) and status of the breakpoint:
- Red
A red icon shows that you have set an unconditional breakpoint, and that the breakpoint is enabled (see Unconditional and conditional breakpoints).
- Yellow
A yellow icon shows that you have assigned a software condition to the breakpoint, and that the breakpoint is enabled (see Unconditional and conditional breakpoints).
- White
A white icon shows that you have disabled an existing breakpoint. When you re-enable the breakpoint, the icon changes back to the color it had before the breakpoint was disabled.
This color coding is also reflected in the Break/Tracepoints pane.
Note
Hardware access, read, and write breakpoints are not shown in the File Editor pane, because there is no specific line or context to display them.
If you try to set a breakpoint on a non-executable line, RealView Debugger places the breakpoint at the first line of executable code after your chosen location. If the lines preceding the breakpointed instruction are comments, declarations, or other non-executable code, they are marked with downward pointing arrows, shown in Figure 10.1. Lines marked in this way are regarded as part of the breakpoint.
Note
If your image is compiled with a high optimization level, then the effect of setting a breakpoint in the source view depends on where you set the breakpoint. For example, if you set a breakpoint on an inlined function, then a breakpoint is created for each instance of that inlined function.
PDF version