|Non-Confidential||PDF version||ARM DUI0446Z|
|Home > Controlling Target Execution > Overview: Breakpoints and Watchpoints|
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.
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:
Conditional breakpoints trigger when an expression evaluates to true or when an ignore counter is reached. See Conditional breakpoints for more information.
Temporary breakpoints can be hit only once and are automatically deleted afterwards.
A script file is assigned to a specific breakpoint. When the breakpoint is triggered, then the script assigned to it is executed.
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.
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.
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.