Debugging a Program With dbx

Listing and Clearing Event Handlers

Often, you set more than one breakpoint or trace handler during a debugging session. dbx supports commands for listing and clearing them.

Listing Breakpoints and Traces

To display a list of all active breakpoints, use the status command to print ID numbers in parentheses, which can then be used by other commands.

As noted, dbx reports multiple breakpoints set with the inmember, inclass, and infunction keywords as a single set of breakpoints with one status ID number.

Deleting Specific Breakpoints Using Handler ID Numbers

When you list breakpoints using the status command, dbx prints the ID number assigned to each breakpoint when it was created. Using the delete command, you can remove breakpoints by ID number, or use the keyword all to remove all breakpoints currently set anywhere in the program.

To delete breakpoints by ID number:

(dbx) delete 3 5

To delete all breakpoints set in the program currently loaded in dbx:

(dbx) delete all

Watchpoints

Watchpointing is the capability of dbx to note when the value of a variable or expression has changed.

Stopping Execution When Modified

To stop program execution when the contents of an address is written to:

(dbx) stop modify &variable

Keep these points in mind when using stop modify:

The event occurs when a variable gets written to even if it is the same value.

The event occurs before the instruction that wrote to the variable is executed, although the new contents of the memory are preset by dbx by emulating the instruction.

You cannot use addresses of stack variables, for example, auto function local variables.

Stopping Execution When Variables Change

To stop program execution if the value of a specified variable has changed:

(dbx) stop change variable

Keep these points in mind when using stop change:

dbx stops the program at the line after the line that caused a change in the value of the specified variable.

If variable is local to a function, the variable is considered to have changed when the function is first entered and storage for variable is allocated. The same is true with respect to parameters.

dbx implements stop change by causing automatic single stepping together with a check on the value at each step. Stepping skips over library calls. So, if control flows in the following manner:
```
   user_routine calls
      library_routine, which calls
        user_routine2, which changes variable
```
dbx does not trace the nested user_ routine2 because tracing skips the library call and the nested call to user_routine2, so the change in the value of variable appears to have occurred after the return from the library call, not in the middle of user_routine2.

dbx cannot set a breakpoint for a change in a block local variable--a variable nested in {}. If you try to set a breakpoint or trace in a block local "nested" variable, dbx issues an error informing you that it cannot perform this operation.

Stopping Execution on a Condition

To stop program execution if a conditional statement evaluates to true:

(dbx) stop cond condition

The Faster `modify` Event

A faster way of setting watchpoints is to use the modify command. Instead of automatically single-stepping the program, it uses a page protection scheme which is much faster. The speed depends on how many times the page on which the variable you are watching is modified, as well as the overall system call rate of the program being debugged.