Breakpoints and watchpoints enable you to stop the target when certain events occur, and when certain conditions are met. When execution stops you can then choose to examine the contents of memory, registers, or variables, or you might have specified other actions to be taken before execution resumes.
The debugger provides the following types:
A breakpoint enables you to interrupt your application when execution reaches a specific address. A breakpoint is always related to a particular memory address, regardless of what might be stored there. When execution reaches the breakpoint, normal execution stops before any instruction stored there is performed.
You can set:
software breakpoints that trigger when a particular instruction is executed at a specific address
hardware breakpoints that trigger when the processor attempts to execute an instruction that is fetched from a specific memory address
conditional breakpoints that trigger when an expression evaluates to true or when an ignore counter is reached
temporary software or hardware breakpoints that are subsequently deleted when the breakpoint is hit.
The type of breakpoints you can set depends on the:
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.
A watchpoint is similar to a breakpoint, but it is the address or value of a data access that is monitored rather than an instruction being executed from a specific address. You specify a register or a memory address to identify a location that is to have its contents tested. 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:
watchpoints that trigger when a particular memory location is accessed in a particular way
conditional watchpoints that trigger when an expression evaluates to true or when an ignore counter is reached.
Be aware of the following when setting breakpoints and watchpoints:
The number of hardware breakpoints available depends on the target.
If an image is compiled with a high optimization level or perhaps 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 or 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.
Watchpoints are only supported on global/static data symbols because they are always in scope. Local variables are not available when you step out of a function.
Some targets do not support watchpoints. Currently you can only use watchpoint commands on a hardware target using a debug hardware agent.
The address of the instruction that triggers the watchpoint might not be the address shown in the PC register. This is because of pipelining effects in the processor.
When debugging an application that uses shared objects, breakpoints that are set within a shared object are deleted when the shared object is unloaded.
If a breakpoint is set by function name then only inline instances that have been already demand loaded are found. To find all the inline instances of a function you must disable on-demand loading.