Sun Studio 12 Update 1: Debugging a Program With dbx

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

where:

-a

Specifies all modules

-f

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

-q

Specifies quiet mode.

-v

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

where:

-v

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