Debugging a Program With dbx |
Setting Breakpoints and Traces
A breakpoint is a location where an action occurs, at which point the program stops executing. You can set a trace that displays information about an event in your program, such as a change in the value of a variable. Although a trace's behavior is different from that of a breakpoint, traces and breakpoints share similar event handlers.
This chapter describes how to set, clear, and list breakpoints and traces, and how to use watchpoints.
The chapter is organized into the following sections:
- Setting Breakpoints
- Tracing Code
- Listing and Clearing Event Handlers
- Setting Breakpoint Filters
- Efficiency Considerations
Setting Breakpoints
In
dbx
, you can use three types of breakpoint action commands to set source-level breakpoints:
stop
breakpoints-If the program arrives at a breakpoint created with astop
command, the program halts. The program cannot resume until you issue another debugging command, such ascont
,step
, ornext
.when
breakpoints-The program halts anddbx
executes one or more debugging commands, then the program continues (unless one of the commands isstop
).trace
breakpoints-The program halts and an event-specifictrace
information line is emitted, then the program continues.To set machine-level breakpoints, use the
stopi
,wheni
, andtracei
commands (see Chapter 17).Setting a
stop
Breakpoint at a Line of Source CodeYou can set a breakpoint at a line number, using the
dbx
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 in a
stop
orwhen
command 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 also set a breakpoint at a location in the Sun WorkShop Breakpoints window. For more information, see "Breaking at a Location" in the Using the Debugging Window section of the Sun WorkShop online help.
Setting a
stop
Breakpoint in a FunctionYou can set a breakpoint in a function, using the
dbx
stop in
command:
(dbx)
stop in
functionAn In Function breakpoint suspends program execution at the beginning of the first source line in a procedure or function.
You can also set a breakpoint in a function in the Sun WorkShop Breakpoints window. For more information, see "Breaking in a Function" in the Using the Debugging Window section of the Sun WorkShop online help.
dbx should be able to determine which variable or function you are referring to except when:
- You reference an overloaded function by name only.
- You reference a function or variable with a leading `'.
Consider the following example:
int foo(double);int foo(int); int bar(); class x { int bar();};When you 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()
dbx
cannot determin whether you mean the global functionfoo(int)
or the global functionfoo(double
) and may be forced to display an overloaded menu for clarification.
dbx
cannot determine whether you mean the global functionbar()
or the member functionbar()
and display an overloaded menu.Setting a
when
Breakpoint at a LineA
when
breakpoint command accepts otherdbx
commands such aslist
, letting you write your own version oftrace
.
(dbx)
when at 123 { list $lineno;}
The
when
command operates with an impliedcont
command. In the example above, after listing the source code at the current line, the program continues executing.Setting a Breakpoint in a Dynamically Linked Library
dbx
provides full debugging support for code that uses the programmatic interface to the run-time linker: code that callsdlopen()
,dlclose()
and their associated functions. The run-time linker binds and unbinds shared libraries during program execution. Debugging support fordlopen()/dlclose()
lets you step into a function or set a breakpoint in functions in a dynamically shared library just as you can in a library linked when the program is started.
- You cannot set a breakpoint in a library loaded by
dlopen()
before that library is loaded bydlopen()
.- You cannot set a breakpoint in a filter library loaded by
dlopen()
until the first function in it is called.- When a library is loaded by
dlopen()
, an initialization routine named_init()
is called. This routine may call other routines in the library.dbx
cannot place breakpoints in the loaded library until after this initialization is completed. You cannot havedbx
stop at_init()
in a library loaded bydlopen()
.Setting Multiple Breaks in C++ Programs
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
, orinobject
--with astop
,when
, ortrace
command to set multiple breaks in C++ code.Setting Breakpoints in Member Functions of Different Classes
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
.To set a
when
breakpoint, usewhen 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
You can also set an In Member breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Setting an In Member Breakpoint" in the Using the Debugging Window section of the Sun WorkShop online help.
Setting Breakpoints in Member Functions of the Same Class
To set a breakpoint in all member functions of a specific class, use the
stop inclass
command.To set a
when
breakpoint, usewhen inclass
.To set a breakpoint in all member functions of the class
draw
, type:
(dbx)
stop inclass draw
You can also set an In Class breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Setting an In Class Breakpoint" in the Using the Debugging Window section of the Sun WorkShop online help.
Breakpoints are inserted only in the class member functions defined in the class, not those that it might inherit from base classes.
Due to the large number of breakpoints that may be inserted by
stop inclass
and other breakpoint selections, you should be sure to set thedbx
environment variablestep_events
toon
to speed up thestep
andnext
commands (see Efficiency Considerations).Setting Multiple Breakpoints in Nonmember Functions
To set multiple breakpoints in nonmember functions with overloaded names (same name, different type or number of arguments), use the
stop infunction
command.To set a
when
breakpoint, usewhen infunction
.For example, if a C++ program has defined two versions of a function named
sort()
(one that passes anint
type argument and the other afloat
) then, to place a breakpoint in both functions, type:
(dbx)
when infunction sort {cmd;}
You can also set an In Function breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Breaking in a Function" in the Using the Debugging Window section of the Sun WorkShop online help.
Setting Breakpoints in Objects
Set an In Object breakpoint to check the operations applied to a specific object. An In Object breakpoint suspends program execution in all nonstatic member functions of the object's class when called from the object.
To set a breakpoint in object
foo
, type:
(dbx)
stop inobject &foo
You can also set an In Object breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Setting an In Object Breakpoint" in the Using the Debugging Window section of the Sun WorkShop online help.
Tracing Code
Tracing displays information about the line of code about to be executed, a function about to be called, or a variable about to be changed. For more information, see "Code Tracing" in the Using the Debugging Window section of the Sun WorkShop online help.
Setting a Trace
Set a trace by typing a
trace
command at the command line. The basic syntax of thetrace
command is:
trace event-specification [ modifier ]For the complete syntax of the trace command, see "trace Command" in the Using dbx Commands section of the Sun WorkShop online help.
You can also set a trace in the Sun WorkShop Breakpoints window. For more information, see "Setting Up a Trace" in the Using the Debugging Window section of the Sun WorkShop online help.
The information a trace provides depends on the type of event associated with it (see Setting Event Specifications.
Controlling the Speed of a Trace
In many programs, code execution is too fast for you to view the code. The
dbx
environment variabletrace_speed
lets you control the delay after each trace is printed. The default delay is0.5
seconds.To set the interval between execution of each line of code during a trace, type:
dbxenv trace_speed
numberYou can also set the speed of a trace in the Sun WorkShop Debugging Options dialog box. For more information, see "Setting the Trace Speed" in the Using the Debugging Window section of the Sun WorkShop online help.
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 display ID numbers in parentheses, which can then be used by other commands.
dbx
reports multiple breakpoints set with theinmember
,inclass
, andinfunction
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
displays the ID number assigned to each breakpoint when it was created. Using thedelete
command, you can remove breakpoints by ID number, or use the keywordall
to remove all breakpoints currently set anywhere in the program.To delete breakpoints by ID number, type:
(dbx)
delete 3 5
To delete all breakpoints set in the program currently loaded in
dbx
, type:
(dbx)
delete all
For more information, see "delete Command" in the Using dbx Commands section of the Sun WorkShop online help.
Watchpoints
Watchpointing is the capability of
dbx
to note when the value of a variable or expression has changed. You can set watchpoints using thestop
command.Stopping Execution When Modified
To stop program execution when the contents of an address is written to, type:
(dbx)
stop modify
&
variableKeep these points in mind when using the
stop modify
command:
- The event occurs when a variable is 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.
You can also set an On Modify breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Setting a Custom On Value Change Breakpoint" in the Using the Debugging Window section of the Sun WorkShop online help.
Stopping Execution When Variables Change
To stop program execution if the value of a specified variable has changed, type:
(dbx)
stop change
variableKeep 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.
You can also set an On Value Change breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Breaking On Value Change" in the Using the Debugging Window section of the Sun WorkShop online help.
dbx
implementsstop 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 nesteduser_ routine2
because tracing skips the library call and the nested call touser_-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.Stopping Execution on a Condition
To stop program execution if a conditional statement evaluates to true, type:
(dbx)
stop cond
conditionYou can also set a custom On Condition breakpoint in the Sun WorkShop Breakpoints window. For more information, see "Setting a Custom On Condition Breakpoint" in the Using the Debugging Window section of the Sun WorkShop online help.
Faster
modify
EventA faster way of setting watchpoints is to use the
modify
event. See "Predefined Events" in the Using dbx Commands section of the Sun WorkShop online help.Instead of automatically single-stepping the program, the
modify
event uses a page protection scheme that 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.Setting Breakpoint Filters
In
dbx
, most of the event management commands also support an optional event filter modifier statement. The simplest filter instructsdbx
to test for a condition after the program arrives at a breakpoint or trace handler, or after a watch condition occurs. For information on event modifiers, see Event Specification Modifiers.If this filter condition evaluates to true (non 0), the event command applies. If the condition evaluates to false (0),
dbx
continues program execution as if the event had never happened.To set a breakpoint at a line or in a function that includes a conditional filter, add an optional
-if
condition modifier statement to the end of astop
ortrace
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.
Note With a location-based breakpoint likein
orat
, the scope 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 syntax to specify the scope precisely.
For example, 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.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 modify &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 tofast_enough
. If it is not, the program continues, "ignoring" thestop
.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]
Efficiency Considerations
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. This is becausedbx
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 everycont
.
Note In the case ofstep
andnext
, 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 ofstep
andnext
slows down considerably. Use thedbx step_events
environment variable to control whether breakpoints are taken out and reinserted after eachstep
ornext
.
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 watchpointsstop change
expression ortrace 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 thetrace
is effective in the functions called bymain
as well. Do use it in the cases where you suspect that thelookup()
function is clobbering your variable.
Sun Microsystems, Inc. Copyright information. All rights reserved. Feedback |
Library | Contents | Previous | Next | Index |