Using the Auto-Read Facility

In general, you should compile the entire program you want to debug using the -g option. Depending on how the program was compiled, the debugging information generated for each program and shared library module is stored in either the object code file (.o file) for each program and shared library module, and/or the program executable file.

When you compile with the -g -c compiler option, debugging information for each module remains stored in its .o file. dbx then reads in debugging information for each module automatically, as it is needed, during a session. This read-on-demand facility is called Auto-Read. Auto-Read is the default for dbx.

Auto-Read saves considerable time when loading a large program into dbx. Auto-Read depends on the continued presence of the program .o files in a location known to dbx.

If you archive .o files into .a files, and then link using the archive libraries, you can then remove the associated .o files, but you must keep the .a files.

By default, dbx looks for files in the directory where they were when the program was compiled and the .o files in the location from which they were linked. If the files are not there, use the pathmap command to set the search path.

If no object file is produced, debugging information is stored in the executable. That is, for a compilation that does not produce .o files, the compiler stores all the debugging information in the executable. The debugging information is read the same way as for applications compiled with the -xs option. See "Debugging Without the Presence of .o Files"."

Debugging Without the Presence of .o Files

Programs compiled with -g -c store debugging information for each module in the module's .o file. Auto-Read requires the continued presence of the program and shared library .o files.

In circumstances where it is not feasible to keep program .o files or shared library .o files for modules that you want to debug, compile the program using the compiler -xs option (use this option in addition to -g). You can have some modules compiled with -xs and some without. The -xs option instructs the compiler to have the linker place all of the debugging information in the program executable; therefore the .o files do not have to be present in order to debug those modules.

In dbx 4.0, the debugging information for modules compiled with the -xs option is loaded during dbx startup. For a large program compiled with -xs, this may cause dbx to start slowly.

In dbx 5.0, the loading of debugging information for modules compiled with -xs is also delayed in the same way as the debugging information stored in .o files. However, you can instruct dbx to load the debugging information for modules compiled with -xs during startup. The dbx environment variable delay_xs lets you turn off the delayed loading of debugging information for modules compiled with -xs. To set the environment variable, add this line to your .dbxrc file:

dbxenv delay_xs off

Listing Modules

The dbx modules 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:

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

To read in debugging information for all modules:

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