JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Debugging a Program With dbx     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information


1.  Getting Started With dbx

2.  Starting dbx

3.  Customizing dbx

4.  Viewing and Navigating To Code

Navigating To Code

Navigating To a File

Navigating To Functions

Selecting From a List of C++ Ambiguous Function Names

Choosing Among Multiple Occurrences

Printing a Source Listing

Walking the Call Stack to Navigate To Code

Types of Program Locations

Program Scope

Variables That Reflect the Current Scope

Visiting Scope

Components of the Visiting Scope

Changing the Visiting Scope

Qualifying Symbols With Scope Resolution Operators

Backquote Operator

C++ Double Colon Scope Resolution Operator

Block Local Operator

Linker Names

Locating Symbols

Printing a List of Occurrences of a Symbol

Determining Which Symbol dbx Uses

Scope Resolution Search Path

Relaxing the Scope Lookup Rules

Viewing Variables, Members, Types, and Classes

Looking Up Definitions of Variables, Members, and Functions

Looking Up Definitions of Types and Classes

Debugging Information in Object Files and Executables

Object File Loading

Listing Debugging Information for Modules

Listing Modules

Finding Source and Object Files

5.  Controlling Program Execution

6.  Setting Breakpoints and Traces

7.  Using the Call Stack

8.  Evaluating and Displaying Data

9.  Using Runtime Checking

10.  Fixing and Continuing

11.  Debugging Multithreaded Applications

12.  Debugging Child Processes

13.  Debugging OpenMP Programs

14.  Working With Signals

15.  Debugging C++ With dbx

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

20.  Debugging Shared Libraries

A.  Modifying a Program State

B.  Event Management

C.  Macros

D.  Command Reference


Debugging Information in Object Files and Executables

Generally, you want to compile your source files with the -g option to make your program more debuggable. The -g option causes the compilers to record debugging information (in stabs or Dwarf format) into the object files along with the code and data for the program.

dbx parses and loads debugging information for each object file (module) on demand, when the information is needed. You can ask dbx to load debug information for any specific module, or for all modules, by using the module command. See also Finding Source and Object Files.

Object File Loading

When the object (.o) files are linked together, the linker can optionally store only summary information into the resulting loadobject. This summary information can be used by dbx at runtime to load the rest of the debug information from the object files themselves instead of from the executable file. The resulting executable has a smaller disk-footprint, but requires that the object files be available when dbx runs.

You can override this requirement by compiling object files with the -xs option to cause all the debugging information for those object files to be put into the executable at link time.

If you create archive libraries (.a files) with your object files, and use the archive libraries in your program, then dbx extracts the object files from the archive library as needed. The original object files are not needed at that point.

The only drawback to putting all the debugging information into the executable file is using additional disk space. The program does not run more slowly, because the debugging information is not loaded into the process image at run time.

The default behavior when using stabs is for the compiler to put only summary information into the executable.

The DWARF format doesn’t yet support object file loading.

Note - The DWARF format is significantly more compact than recording the same information in stabs format. However, because all the information is copied into the executable, DWARF information can appear to be larger than stabs information.

Listing Debugging Information for Modules

The module command and its options help you to keep track of program modules during the course of a debugging session. Use the module command to read in debugging information for one or all modules. Normally, dbx automatically and “lazily” reads in debugging information for modules as needed.

To read in debugging information for a module name, type:

(dbx) module [-f] [-q] name

To read in debugging information for all modules, type:

(dbx) module [-f] [-q] -a



Specifies all modules


Forces reading of debugging information, even if the file is newer than the executable.


Specifies quiet mode.


Specifies verbose mode, which prints language, file names, and so on. This is the default.

To print the name of the current module, type:

(dbx) module

Listing Modules

The modules command helps you keep track of modules by listing module names.

To list the names of modules containing debugging information that have already been read into dbx, type:

(dbx) modules [-v] -read

To list names of all program modules (whether or not they contain debugging information), type:

(dbx) modules [-v]

To list all program modules that contain debugging information, type:

(dbx) modules [-v] -debug



Specifies verbose mode, which prints language, file names, and so on.