Setting Filters on Breakpoints

In dbx, most of the event management commands also support an optional event filter modifier. The simplest filter instructs dbx to test for a condition after the program arrives at a breakpoint or trace handler, or after a data change breakpoint occurs.

If this filter condition evaluates to true (non 0), the event command applies and program execution stops at the breakpoint. If the condition evaluates to false (0), dbx continues program execution as if the event had never happened.

To set a breakpoint that includes a filter at a line or in a function, add an optional- if condition modifier statement to the end of a stop or trace command.

The condition can be any valid expression, including function calls, returning Boolean or integer in the language current at the time the command is entered.

With a location-based breakpoint like in or at, the scope for parsing the condition is that of the breakpoint location. Otherwise, the scope of the condition is the scope at the time of entry, not at the time of the event. You might have to use the backquote operator (see Backquote Operator) to specify the scope precisely.

These two filters are not the same:

stop in foo -if a>5
stop cond a>5

The former breaks at foo and tests the condition. The latter automatically single steps and tests for the condition.

Using the Return Value of a Function Call as a Filter

You can use a function call as a breakpoint filter. In this example, if the value in the string str is abcde, then execution stops in function foo():

(dbx) stop in foo -if !strcmp(“abcde”,str)

Setting Data Change Breakpoints on Local Variables

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 enables 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.

Using a Filter With a Conditional Event

New 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]

If you set a breakpoint with a filter that contains function calls in a multithreaded program, dbx stops execution of all threads when it hits the breakpoint, and then evaluates the condition. If the condition is met and the function is called, dbx resumes all threads for the duration of the call.

For example, you might set the following breakpoint in a multithreaded application where many threads call lookup():

(dbx) stop in lookup -if strcmp(name, “troublesome”) == 0

dbx stops when thread t@1 calls lookup(), evaluates the condition, and calls strcmp() resuming all threads. If dbx hits the breakpoint in another thread during the function call, it issues a warning such as one of the following:

event infinite loop causes missed events in the following handlers:
...

Event reentrancy
first event BPT(VID 6m TID 6, PC echo+0x8)
second event BPT*VID 10, TID 10, PC echo+0x8)
the following handlers will miss events:
...

In such a case, if you can ascertain that the function called in the conditional expression will not grab a mutex, you can use the -resumeone event specification modifier to force dbx to resume only the first thread in which it hit the breakpoint. For example, you might set the following breakpoint:

(dbx) stop in lookup -resumeone -if strcmp(name, “troublesome”) == 0

The -resumeone modifier does not prevent problems in all cases. For example, it would not help if:

• The second breakpoint on lookup() occurs in the same thread as the first because the condition recursively calls lookup().

• The thread on which the condition runs relinquishes control to another thread.

For detailed information on event modifiers, see Event Specification Modifiers.