Conditional breakpoints have properties assigned to test for conditions that must be satisfied to trigger the breakpoint. For example, 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.
Conditional breakpoints can be very intrusive and lower the performance if they are hit frequently. This is because the debugger stops the target every time the breakpoint triggers. The specified condition is checked and if it evaluates to true then the target remains in the stopped state, otherwise execution resumes.
Note
You must not assign a script to a breakpoint that has sub-breakpoints. If you do, the debugger attempts to execute the script for each sub-breakpoint. If this happens, an error message is displayed.
You can assign conditions to an existing breakpoint in the Breakpoint Properties dialog box:
In the Breakpoints view, right-click on the breakpoint that you want modify to display the context menu.
Select Properties... to display the Breakpoint Properties dialog box.
If you want to set a conditional expression for a specific breakpoint then enter a C-style expression in the Stop Condition field. For example, if your application has a variable
x, then you can specify:x == 10If you want the debugger to delay hitting the breakpoint until a specific number of passes has occurred, then enter the number of passes in the Ignore Count field. For example, if you have a loop that performs 100 iterations, and you want a breakpoint in that loop to be hit after 50 passes, then enter 50.
If you want to run a script when the selected breakpoint is triggered then specify the script file in the On break, run script field:
enter the location and file name in the field provided
click on File System... to locate the file in an external directory from the workspace
click on Workspace... to locate the file in a project directory or sub-directory within the workspace.
Note
Take care with the commands used in a script file that is attached to a breakpoint. For example, if the script file contains the quit command, the debugger disconnects from the target when the breakpoint is hit.
If you want to enable the debugger to automatically continue running the application on completion of all the breakpoint actions then select the Continue Execution checkbox.
Alternatively you can enter the continue command as the last command in a script file, that is attached to a breakpoint.
If you want to set a breakpoint in one or more threads or processors:
Select Break on Selected Threads or Cores to enable the selection panel.
Select the checkbox for each thread or processor that you want to assign the breakpoint to.
Click OK to save the changes.
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.
Considerations when setting multiple conditions on
a breakpointBe 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
cand has 10 iterations .If you set the Stop Conditionc==5and the Ignore Count to3, then the breakpoint might not activate until it has been hit withc==5for the fourth time. It subsequently activates every time it is hit withc==5.If you choose to break on 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
condition
ignore count.
- Tasks
- Concept
- Reference
PDF version