|Non-Confidential||PDF version||ARM DUI0446Z|
|Home > Controlling Target Execution > Conditional breakpoints|
Conditional breakpoints have properties assigned to test for conditions that must be satisfied to trigger the breakpoint. When the underlying breakpoint is hit, the specified condition is checked and if it evaluates to true, then the target remains in the stopped state, otherwise execution resumes.
For example, using conditional breakpoints, you can:
Test a variable for a given value.
Execute a function a set number of times.
Trigger a breakpoint only on a specific thread or processor.
Breakpoints that are set on a single line of source code with multiple statements are assigned as sub-breakpoints to a parent breakpoint. You can enable, disable, and view the properties of each sub-breakpoint in the same way as a single statement breakpoint. Conditions are assigned to top level breakpoints only and therefore affect both the parent breakpoint and sub-breakpoints.
Conditional breakpoints can be very intrusive and lower the performance if they are hit frequently since the debugger stops the target every time the breakpoint triggers.
Be aware of the following when setting multiple conditions on a breakpoint:
If you set a Stop
Condition and an Ignore
Count, then the Ignore
Count is not decremented until the Stop Condition is met. For example, you
might have a breakpoint in a loop that is controlled by the variable
c and has 10 iterations. If you set the
c==5 and the Ignore Count to
the breakpoint might not activate until it has been hit with
c==5 for the fourth time. It subsequently
activates every time it is hit with
If you choose to break on a selected thread or processor, then the Stop Condition and Ignore Count are checked only for the selected thread or processor.
Conditions are evaluated in the following order:
Thread or processor.