Breakpoints and watchpoints enable you to stop the target when certain events occur and when certain conditions are met. When execution stops, you can choose to examine the contents of memory, registers, or variables, or you can specify other actions to take before resuming execution.
Breakpoints
A breakpoint enables you to interrupt your application when execution reaches
a specific address. When execution reaches the breakpoint, normal execution stops
before any instruction stored there is executed.
Types of breakpoints:
-
Software breakpoints stop your program when execution reaches a specific
address.
Software breakpoints are implemented by the debugger
replacing the instruction at the breakpoint address with a special
instruction. Software breakpoints can only be set in RAM.
-
Hardware breakpoints use special processor hardware to interrupt application
execution. Hardware breakpoints are a limited resource.
You can configure breakpoint properties to make them:
Note
- Memory region and the related access attributes.
- Hardware support provided by your target processor.
- Debug interface used to maintain the target connection.
- Running state if you are debugging an OS-aware
application.
The
Target view shows the breakpoint capabilities of the
target.
Considerations when setting breakpoints
Be aware of the following when setting breakpoints:
-
The number of hardware breakpoints available depends on your processor. Also,
there is a dependency between the number of hardware breakpoints and
watchpoints because they use the same processor hardware.
-
If an image is compiled with a high optimization level or contains C++
templates, then the effect of setting a breakpoint in the source code
depends on where you set the breakpoint. For example, if you set a
breakpoint on an inlined function in a C++ template, then a breakpoint is
created for each instance of that function or template. Therefore the target
can run out of breakpoint resources.
-
Enabling a Memory Management
Unit (MMU) might set a memory region to read-only. If that memory
region contains a software breakpoint, then that software breakpoint cannot
be removed. Therefore, make sure you clear software breakpoints before
enabling the MMU.
-
When debugging an application that uses shared objects, breakpoints that are
set within a shared object are re-evaluated when the shared object is
unloaded. Those with addresses that can be resolved are set and the others
remain pending.
-
If a breakpoint is set by function name, then only inline instances that have
been already
demand loaded are found.
Watchpoints
A watchpoint is similar to a breakpoint, but it is the address of a data
access that is monitored rather than an instruction being executed. You specify a
global variable or a memory address to monitor. Watchpoints are sometimes known as
data breakpoints, emphasizing that they are data dependent. Execution of your
application stops when the address being monitored is accessed by your application.
You can set read, write, or read/write watchpoints.
Considerations when setting watchpoints
Be aware of the following when setting watchpoints:
-
Depending on the target, it is possible that a few additional instructions,
after the instruction that accessed the variable, might also be executed.
This is because of pipelining effects in the processor. This means that the
address that your program stops at might not exactly correspond with the
instruction that caused the watchpoint to trigger.
-
Watchpoints are only supported on scalar values.
-
Watchpoints are only supported on global or static data symbols because they
are always in scope and at the same address. Local variables are no longer
available when you step out of a particular function.
-
The number of watchpoints that can be set at the same time depends on the
target and the debug connection being used.
-
Some targets do not support watchpoints.
PDF version