Inexperienced users sometimes confuse setting a conditional event command (a watch-type command) with using filters. Conceptually, “watching” creates a precondition that must be checked before each line of code executes (within the scope of the watch). But even a breakpoint command with a conditional trigger can also have a filter attached to it.
Consider this example:
(dbx) stop access w &speed -if speed==fast_enough
This command instructs dbx to monitor the variable, speed; if the variable speed is written to (the “watch” part), then the -if filter goes into effect. dbx checks whether the new value of speed is equal to fast_enough. If it is not, the program continues, “ignoring” the stop command.
In dbx syntax, the filter is represented in the form of an [-if condition] statement at the end of the command.
stop in function [-if condition]
Consider a simple example, in which you have code like the following:
44: if(open(filename, ...) == -1) 45: return "Error";
You can stop on a specific failure, for example ENOENT of open() with the following command:
(dbx) stop at 45 -if errno == 2
Filters can be convenient when you are placing a data change breakpoint on a local variable. In the following example, the current scope is in function foo(), while index, the variable of interest, is in function bar().
(dbx) stop access w &bar`index -in bar
bar`index ensures that the index variable in function bar() is picked up, instead of the index variable in function foo or a global variable named index.
-in bar implies the following:
The breakpoint is automatically enabled when function bar() is entered.
The breakpoint remains enabled for the duration of bar() including any functions it calls.
The breakpoint is automatically disabled upon return from bar().
The stack location corresponding to index might be reused by some other local variable of some other function. -in ensures that the breakpoint is triggered only when bar`index is accessed.