Conditional watchpoints have properties that are assigned to test for conditions that must be satisfied to trigger the watchpoint. When the conditional watchpoint is hit, the specified condition is checked and if it evaluates to true, the watchpoint is triggered, and the target stops.
For example, using conditional watchpoints you can:
- Set a watchpoint to stop when accessing data from a memory region, but only when a variable evaluates to a given value.
- On processors that implement virtualization extensions, you can set a watchpoint to trigger only when running within a specific virtual machine (determined through its Virtual Machine ID (VMID)).
- On all Arm®v7 and Armv8 processors, you can set a watchpoint to trigger only when a specific process is running, as defined by the current Context ID.
- Conditional watchpoints are not supported on gdbserver connections currently.
- You can create several conditional watchpoints, but when a conditional watchpoint is enabled, no other watchpoints (regardless of whether they are conditional) can be enabled.
- Conditional watchpoints can be intrusive and lower performance if they are hit frequently since the debugger stops the target every time the watchpoint triggers.
See Working with watchpoints for details about assigning a condition to watchpoint when creating it. See Assigning conditions to an existing watchpoint for details about assigning conditions to an existing watchpoint.
Considerations when creating conditional watchpoints
- If the instruction causing the trap occurred synchronously, then to evaluate a condition after any state has changed (for example, a store to an address), the debugger steps the instruction that caused the trap. The debugger then proceeds to evaluate the condition to see whether to stop on the watchpoint. This is required so that a specific address can be watched and trap immediately after a specific value is written to that address.
- Ignore count or core/thread specific watchpoints are not supported.