dbx can recognize macro definitions in two ways:
Definitions are provided by the compilers when you compile with the –g3 option if you use the default DWARF format for debugging information. They are not provided if you specify the –xdebugformat=stabs option when compiling.
dbx can re-create definitions by skimming the source file and its include files. Accurate re-creation depends on access to the original sources and include files. It also depends on the availability of the path name to the compiler used, and on compiler options like –D and –I. This information is available in both DWARF and stabs formats from Oracle Developer Studio compiler, but not from GNU compilers. See Skimming Errors and Using the pathmap Command to Improve Skimming for information about ensuring successful skimming.
The dbxenv variable macro_source (see Table 1 in Customizing dbx) controls which one of the two methods dbx uses to recognize macro definitions.
There are several factors to take into account in choosing which method you want dbx to use.
One factor in choosing a macro definition method is the availability of various types of information that depend on which compiler and compiler options you used to build your code. The following table shows which methods you can choose depending on the compiler and debugging information options.
|
Another factor to take into account in choosing a macro definition method is the tradeoffs in functionality depending on which method you choose:
Size of executable. The main advantage of the skimming method is that it does not require compilation with the –g3 option because it works with the smaller executables produced by compiling with the –g option.
Debugging format. Skimming works with both DWARF and stabs. Compiling with the –g3 option to get the definitions from the compiler works only with DWARF.
Speed. Skimming takes up to one second the first time an expression is evaluated for a module for which dbx has not yet read the debugging information.
Accuracy. Information provided by the compilers when you compile with the –g3 option is more stable and accurate than information provided by skimming.
Availability of the build environment. Skimming requires that the compilers, source code files, and include files be available during debugging. dbx does not check for these items becoming out of date, so if they are likely to change, accuracy might deteriorate and compiling with the –g3 option might be better than depending on skimming.
Debugging on a different system from the one where the code was compiled. If you compiled the code on system A and are debugging it on system B, dbx accesses files on system A using NFS with some help from the pathmap command.
The pathmap command also helps facilitate file access during skimming. Although it works for your program's source files and include files, it might not work for system include files because /usr/include is not usually available through NFS. Macro definitions therefore are extracted from /usr/include on the debugging system instead of on the build system.
You can choose to be aware of and tolerant of possible discrepancies between system include files, or choose to compile with the –g3 option.
Although Fortran compilers support macros through the cpp(1) function or the fpp(1) function, dbx does not support macro expansion for Fortran.
dbx ignores macro information generated by compiling with the –g3 option and the –xdebugformat=stabs option.
For more information about the stabs index, see the Stab Interface guide,found with the path install-dir/solarisstudio12.6/READMEs/stabs.pdf.
Skimming works with code compiled with the –g option and the –xdebugformat=stabs option.