Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Studio 12.3: Debugging a Program With dbx Oracle Solaris Studio 12.3 Information Library |
4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
Setting a stop Breakpoint at a Line of Source Code
Setting a stop Breakpoint in a Function
Setting Multiple Breaks in C++ Programs
Setting Breakpoints in Member Functions of Different Classes
Setting Breakpoints in All Member Functions of a Class
Setting Multiple Breakpoints in Nonmember Functions
Setting Breakpoints in Objects
Setting Data Change Breakpoints
Stopping Execution When an Address Is Accessed
Setting Filters on Breakpoints
Using the Return Value of a Function Call as a Filter
Setting Data Change Breakpoints on Local Variables
Using a Filter With a Conditional Event
Controlling the Speed of a Trace
Directing Trace Output to a File
Setting a when Breakpoint at a Line
Setting Breakpoints in Dynamically Loaded Libraries
Listing and Clearing Breakpoints
Listing Breakpoints and Traces
Deleting Specific Breakpoints Using Handler ID Numbers
Enabling and Disabling Breakpoints
8. Evaluating and Displaying Data
11. Debugging Multithreaded Applications
16. Debugging Fortran Using dbx
17. Debugging a Java Application With dbx
18. Debugging at the Machine-Instruction Level
19. Using dbx With the Korn Shell
In dbx, you can use three commands to set breakpoints:
stop breakpoints. If the program arrives at a breakpoint created with a stop command, the program halts. The program cannot resume until you issue another debugging command, such as cont, step, or next.
when breakpoint. If the program arrives at a breakpoint created with a when command, the program halts and dbx executes one or more debugging commands, then the program continues (unless one of the executed commands is stop).
trace breakpoints. If a program arrives at a breakpoint created with a trace command, the program halts and an event-specific trace information line is emitted, then the program continues.
The stop, when, and trace commands all take as an argument an event specification, which describes the event on which the breakpoint is based. Event specifications are discussed in detail in Setting Event Specifications.
To set machine-level breakpoints, use the stopi, wheni, and tracei commands (see Chapter 18, Debugging at the Machine-Instruction Level).
Note - When debugging an application that is a mixture of Java code and C JNI (Java Native Interface) code or C++ JNI code, you may want to set breakpoints in code that has not yet been loaded. For information on setting breakpoints on such code, see Setting Breakpoints in Native (JNI) Code.
You can set a breakpoint at a line number, using the stop at command, where n is a source code line number and filename is an optional program file name qualifier.
(dbx) stop at filename:n
For example
(dbx) stop at main.cc:3
If the line specified is not an executable line of source code, dbx sets the breakpoint at the next executable line. If there is no executable line, dbx issues an error.
You can determine the line at which you wish to stop by using the file command to set the current file and the list command to list the function in which you wish to stop. Then use the stop at command to set the breakpoint on the source line:
(dbx) file t.c (dbx) list main 10 main(int argc, char *argv[]) 11 { 12 char *msg = "hello world\n"; 13 printit(msg); 14 } (dbx) stop at 13
For more information on specifying at an location event, see at [filename:]line_number.
You can set a breakpoint in a function, using the stop in command:
(dbx) stop in function
An In Function breakpoint suspends program execution at the beginning of the first source line in a procedure or function.
dbx should be able to determine which function you are referring to except when:
You reference an overloaded function by name only.
You reference a function with a leading `.
You reference a function by its linker name (mangled name I C++). In this case, dbx accepts the name if you prefix it with a # (see Linker Names).
Consider the following set of declarations:
int foo(double); int foo(int); int bar(); class x { int bar(); };
To stop at a non-member function, you can type:
stop in foo(int)
to set a breakpoint at the global foo(int).
To set a breakpoint at the member function you can use the command:
stop in x::bar()
If you type:
stop in foo
dbx cannot determine whether you mean the global function foo(int) or the global function foo(double) and may be forced to display an overloaded menu for clarification.
If you type:
stop in `bar
dbx cannot determine whether you mean the global function bar() or the member function bar() and displays an overload menu.
For more information on specifying an in function event, see in function.
You can check for problems related to calls to members of different classes, calls to any members of a given class, or calls to overloaded top-level functions. You can use a keyword, inmember, inclass, infunction, or inobject, with a stop, when, or trace command to set multiple breaks in C++ code.
To set a breakpoint in each of the object-specific variants of a particular member function (same member function name, different classes), use stop inmember.
For example, if the function draw is defined in several different classes, then to place a breakpoint in each function, type:
(dbx) stop inmember draw
For more information on specifying an inmember or inmethod event, see inmember function inmethod function.
To set a breakpoint in all member functions of a specific class, use the stop inclass command.
By default, breakpoints are inserted only in the class member functions defined in the class, not those that it might inherit from its base classes. To insert breakpoints in the functions inherited from the base classes also, specify the -recurse option.
To set a breakpoint in all member functions defined in the class shape, type:
(dbx) stop inclass shape
To set a breakpoint in all member functions defined in the class shape, and also in functions inherited from the class, type:
(dbx) stop inclass shape -recurse
For more information on specifying an inclass event, see inclass classname [-recurse | -norecurse] and stop Command.
Due to the large number of breakpoints that may be inserted by stop inclass and other breakpoint selections, you should be sure to set the dbx environment variable step_events to on to speed up the step and next commands (see Efficiency Considerations).
To set multiple breakpoints in nonmember functions with overloaded names (same name, different type or number of arguments), use the stop infunction command.
For example, if a C++ program has defined two versions of a function named sort()(one that passes an int type argument and the other a float) then, to place a breakpoint in both functions, type:
(dbx) stop infunction sort
For more information on specifying an infunction event, see infunction function.
Set an In Object breakpoint to check the operations applied to a specific object instance.
By default, an In Object breakpoint suspends program execution in all nonstatic member functions of the object’s class, including inherited ones, when called from the object. To set a breakpoint to suspend program execution in only nonstatic member functions defined in the object’s class and not inherited classes, specify the -norecurse option.
To set a breakpoint in all nonstatic member functions defined in the base class of object foo, and in all nonstatic member functions defined in inherited classes of object foo, type:
(dbx) stop inobject &foo
To set a breakpoint in all nonstatic member functions defined in the class of object foo, but not those defined in inherited classes of object foo, type:
(dbx) stop inobject &foo -norecurse
For more information on specifying an inobject event, see inobject object-expression [-recurse | -norecurse] and stop Command
You can use data change breakpoints in dbx to note when the value of a variable or expression has changed.
To stop execution when a memory address has been accessed, type:
(dbx) stop access mode address-expression [, byte-size-expression]
mode specifies how the memory was accessed. It can be composed of one or all of the letters:
The memory at the specified address has been read.
The memory has been written to.
The memory has been executed.
mode can also contain either of the following:
Stops the process after the access (default).
Stops the process before the access.
In both cases the program counter will point at the accessing instruction. The “before” and “after” refer to the side effect.
address-expression is any expression that can be evaluated to produce an address. If you give a symbolic expression, the size of the region to be watched is automatically deduced; you can override it by specifying byte-size-expression. You can also use nonsymbolic, typeless address expressions; in which case, the size is mandatory.
In the following example, execution will stop execution after any of the four bytes after the memory address 0x4762 has been read
(dbx) stop access r 0x4762, 4
In this example, execution will stop before the variable speed has be written to:
(dbx) stop access wb &speed
Keep these points in mind when using the stop access command:
The event occurs when a variable is written to even if it is the same value.
By default, the event occurs after execution of the instruction that wrote to the variable. You can indicate that you want the event to occur before the instruction is executed by specifying the mode as b.
For more information on specifying an access event, see access mode address-expression [, byte-size-expression] and stop Command.
To stop program execution if the value of a specified variable has changed, type:
(dbx) stop change variable
Keep these points in mind when using the stop change command:
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.
The command does not work with multithreaded applications.
For more information on specifying a change event, see change variable and stop Command.
dbx implements stop change by causing automatic single stepping together with a check on the value at each step. Stepping skips over library calls if the library was not compiled with the -g option. So, if control flows in the following manner, dbx does not trace the nested user_routine2 because tracing skips the library call and the nested call to user_routine2.
user_routine calls library_routine, which calls user_routine2, which changes variable
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.
Note - It is faster to watch data changes using the access event than the change event. Instead of automatically single-stepping the program, the access event uses hardware or OS services that are much faster.
To stop program execution if a conditional statement evaluates to true, type:
(dbx) stop cond condition
The program stops executing when the condition occurs.
Keep these points in mind when using the stop cond command:
dbx stops the program at the line after the line that caused the condition to evaluate to true.
The command does not work with multithreaded applications.
For more information on specifying a condition event, see cond condition-expression and stop Command.