New compiler and linker options give users more freedom to generate and use debug information. Compilers generate an Index for DWARF, similar to index stabs The index is always present and results in faster dbx start-up time, as well as other improvements when debugging with DWARF.
The following is a diagram of the different kinds and locations of debug information, specifically highlighting where the debug data resides:
Figure 5-1 Flow of Debug Information
DWARF by default is loaded into the executable file. The new index makes it possible to leave the DWARF in the object files with the –xs=no option. This results in a smaller executable size and a faster link. The object files must be retained in order to debug. This is similar to how stabs works.
The Oracle Solaris 11.1 linker can send debug information to a separate ancillary file while building the executable. A separate debug file is useful for environments where all the debug information must be moved, installed, or archived. An executable can be run independently, but can also be debugged by people with a copy of its separate debug file.
dbx continues to support the use of the GNU utility objcopy to extract debug information into a separate file, but using the Oracle Solaris linker has the following advantages over objcopy:
The separate debug file is produced as a by-product of the link
A program which was too large to be linked as one file links as two files
The –g1 compiler option is intended for minimal debuggability of deployed applications. Compiling your application with this option produces the file and line number, as well as simple parameter information that is considered crucial during postmortem debugging. For more information, see the compiler man pages and the compiler user guides.