| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Solaris Studio 12.2: Debugging a Program With dbx |
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
Stopping Execution When Variables Change
Stopping Execution on a Condition
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
Various events have different degrees of overhead in respect to the execution time of the program being debugged. Some events, like the simplest breakpoints, have practically no overhead. Events based on a single breakpoint have minimal overhead.
Multiple breakpoints such as inclass, that might result in hundreds of breakpoints, have an overhead only during creation time. dbx uses permanent breakpoints; the breakpoints are retained in the process at all times and are not taken out on every stoppage and put in on every cont command.
Note - In the case of the step command and next command, by default all breakpoints are taken out before the process is resumed and reinserted once the step completes. If you are using many breakpoints or multiple breakpoints on prolific classes, the speed of the step command and next command slows down considerably. Use the dbx step_events environment variable to control whether breakpoints are taken out and reinserted after each step command or next command.
The slowest events are those that utilize automatic single stepping. This might be explicit and obvious as in the trace step command, which single steps through every source line. Other events, like the stop change expression or trace cond variable not only single step automatically but also have to evaluate an expression or a variable at each step.
These events are very slow, but you can often overcome the slowness by bounding the event with a function using the -in modifier. For example:
trace next -in mumble stop change clobbered_variable -in lookup
Do not use trace -in main because the trace is effective in the functions called by main as well. Do use it in the cases where you suspect that the lookup() function is clobbering your variable.
|