3.9 Options for Debugging Your Program or GCC

GCC has various special options that are used for debugging either your program or GCC:

-g

Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.

On most systems that use stabs format, `-g' enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use `-gstabs+', `-gstabs', `-gxcoff+', `-gxcoff', `-gdwarf-1+', or `-gdwarf-1' (see below).

Unlike most other C compilers, GCC allows you to use `-g' with `-O'. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.

Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

The following options are useful when GCC is generated with the capability for more than one debugging format.

-ggdb

Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.

-gstabs

Produce debugging information in stabs format (if that is supported), without GDB extensions. This is the format used by DBX on most BSD systems. On MIPS, Alpha and System V Release 4 systems this option produces stabs debugging output which is not understood by DBX or SDB. On System V Release 4 systems this option requires the GNU assembler.

-gstabs+

Produce debugging information in stabs format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB). The use of these extensions is likely to make other debuggers crash or refuse to read the program.

-gcoff

Produce debugging information in COFF format (if that is supported). This is the format used by SDB on most System V systems prior to System V Release 4.

-gxcoff

Produce debugging information in XCOFF format (if that is supported). This is the format used by the DBX debugger on IBM RS/6000 systems.

-gxcoff+

Produce debugging information in XCOFF format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB). The use of these extensions is likely to make other debuggers crash or refuse to read the program, and may cause assemblers other than the GNU assembler (GAS) to fail with an error.

-gdwarf

Produce debugging information in DWARF version 1 format (if that is supported). This is the format used by SDB on most System V Release 4 systems.

-gdwarf+

Produce debugging information in DWARF version 1 format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB). The use of these extensions is likely to make other debuggers crash or refuse to read the program.

-gdwarf-2

Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on IRIX 6.

-glevel

-ggdblevel

-gstabslevel

-gcofflevel

-gxcofflevel

-gdwarflevel

-gdwarf-2level

Request debugging information and also use level to specify how much information. The default level is 2.

Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, but no information about local variables and no line numbers.

Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use `-g3'.

-p

Generate extra code to write profile information suitable for the analysis program prof. You must use this option when compiling the source files you want data about, and you must also use it when linking.

-pg

Generate extra code to write profile information suitable for the analysis program gprof. You must use this option when compiling the source files you want data about, and you must also use it when linking.

-a

Generate extra code to write profile information for basic blocks, which will record the number of times each basic block is executed, the basic block start address, and the function name containing the basic block. If `-g' is used, the line number and filename of the start of the basic block will also be recorded. If not overridden by the machine description, the default action is to append to the text file `bb.out'.

This data could be analyzed by a program like tcov. Note, however, that the format of the data is not what tcov expects. Eventually GNU gprof should be extended to process this data.

-Q

Makes the compiler print out each function name as it is compiled, and print some statistics about each pass when it finishes.

-ftime-report

Makes the compiler print some statistics about the time consumed by each pass when it finishes.

-fmem-report

Makes the compiler print some statistics about permanent memory allocation when it finishes.

-ax

Generate extra code to profile basic blocks. Your executable will produce output that is a superset of that produced when `-a' is used. Additional output is the source and target address of the basic blocks where a jump takes place, the number of times a jump is executed, and (optionally) the complete sequence of basic blocks being executed. The output is appended to file `bb.out'.

You can examine different profiling aspects without recompilation. Your executable will read a list of function names from file `bb.in'. Profiling starts when a function on the list is entered and stops when that invocation is exited. To exclude a function from profiling, prefix its name with `-'. If a function name is not unique, you can disambiguate it by writing it in the form `/path/filename.d:functionname'. Your executable will write the available paths and filenames in file `bb.out'.

Several function names have a special meaning:

__bb_jumps__

Write source, target and frequency of jumps to file `bb.out'.

__bb_hidecall__

Exclude function calls from frequency count.

__bb_showret__

Include function returns in frequency count.

__bb_trace__

Write the sequence of basic blocks executed to file `bbtrace.gz'. The file will be compressed using the program `gzip', which must exist in your PATH. On systems without the `popen' function, the file will be named `bbtrace' and will not be compressed. Profiling for even a few seconds on these systems will produce a very large file. Note: __bb_hidecall__ and __bb_showret__ will not affect the sequence written to `bbtrace.gz'.

Here's a short example using different profiling parameters in file `bb.in'. Assume function foo consists of basic blocks 1 and 2 and is called twice from block 3 of function main. After the calls, block 3 transfers control to block 4 of main.

With __bb_trace__ and main contained in file `bb.in', the following sequence of blocks is written to file `bbtrace.gz': 0 3 1 2 1 2 4. The return from block 2 to block 3 is not shown, because the return is to a point inside the block and not to the top. The block address 0 always indicates, that control is transferred to the trace from somewhere outside the observed functions. With `-foo' added to `bb.in', the blocks of function foo are removed from the trace, so only 0 3 4 remains.

With __bb_jumps__ and main contained in file `bb.in', jump frequencies will be written to file `bb.out'. The frequencies are obtained by constructing a trace of blocks and incrementing a counter for every neighbouring pair of blocks in the trace. The trace 0 3 1 2 1 2 4 displays the following frequencies:

Jump from block 0x0 to block 0x3 executed 1 time(s) Jump from block 0x3 to block 0x1 executed 1 time(s) Jump from block 0x1 to block 0x2 executed 2 time(s) Jump from block 0x2 to block 0x1 executed 1 time(s) Jump from block 0x2 to block 0x4 executed 1 time(s)

With __bb_hidecall__, control transfer due to call instructions is removed from the trace, that is the trace is cut into three parts: 0 3 4, 0 1 2 and 0 1 2. With __bb_showret__, control transfer due to return instructions is added to the trace. The trace becomes: 0 3 1 2 3 1 2 3 4. Note, that this trace is not the same, as the sequence written to `bbtrace.gz'. It is solely used for counting jump frequencies.

-fprofile-arcs

Instrument arcs during compilation. For each function of your program, GCC creates a program flow graph, then finds a spanning tree for the graph. Only arcs that are not on the spanning tree have to be instrumented: the compiler adds code to count the number of times that these arcs are executed. When an arc is the only exit or only entrance to a block, the instrumentation code can be added to the block; otherwise, a new basic block must be created to hold the instrumentation code.

Since not every arc in the program must be instrumented, programs compiled with this option run faster than programs compiled with `-a', which adds instrumentation code to every basic block in the program. The tradeoff: since gcov does not have execution counts for all branches, it must start with the execution counts for the instrumented branches, and then iterate over the program flow graph until the entire graph has been solved. Hence, gcov runs a little more slowly than a program which uses information from `-a'.

`-fprofile-arcs' also makes it possible to estimate branch probabilities, and to calculate basic block execution counts. In general, basic block execution counts do not give enough information to estimate all branch probabilities. When the compiled program exits, it saves the arc execution counts to a file called `sourcename.da'. Use the compiler option `-fbranch-probabilities' (see section Options that Control Optimization) when recompiling, to optimize using estimated branch probabilities.

-ftest-coverage

Create data files for the gcov code-coverage utility (see section gcov: a GCC Test Coverage Program). The data file names begin with the name of your source file:

sourcename.bb

A mapping from basic blocks to line numbers, which gcov uses to associate basic block execution counts with line numbers.

sourcename.bbg

A list of all arcs in the program flow graph. This allows gcov to reconstruct the program flow graph, so that it can compute all basic block and arc execution counts from the information in the sourcename.da file (this last file is the output from `-fprofile-arcs').

-dletters

Says to make debugging dumps during compilation at times specified by letters. This is used for debugging the compiler. The file names for most of the dumps are made by appending a pass number and a word to the source file name (e.g. `foo.c.00.rtl' or `foo.c.01.sibling'). Here are the possible letters for use in letters, and their meanings:

`A'

Annotate the assembler output with miscellaneous debugging information.

`b'

Dump after computing branch probabilities, to `file.11.bp'.

`B'

Dump after block reordering, to `file.26.bbro'.

`c'

Dump after instruction combination, to the file `file.14.combine'.

`C'

Dump after the first if conversion, to the file `file.15.ce'.

`d'

Dump after delayed branch scheduling, to `file.29.dbr'.

`D'

Dump all macro definitions, at the end of preprocessing, in addition to normal output.

`e'

Dump after SSA optimizations, to `file.05.ssa' and `file.06.ussa'.

`E'

Dump after the second if conversion, to `file.24.ce2'.

`f'

Dump after life analysis, to `file.13.life'.

`F'

Dump after purging ADDRESSOF codes, to `file.04.addressof'.

`g'

Dump after global register allocation, to `file.19.greg'.

`o'

Dump after post-reload CSE and other optimizations, to `file.20.postreload'.

`G'

Dump after GCSE, to `file.08.gcse'.

`i'

Dump after sibling call optimizations, to `file.01.sibling'.

`j'

Dump after the first jump optimization, to `file.02.jump'.

`J'

Dump after the last jump optimization, to `file.27.jump2'.

`k'

Dump after conversion from registers to stack, to `file.29.stack'.

`l'

Dump after local register allocation, to `file.18.lreg'.

`L'

Dump after loop optimization, to `file.09.loop'.

`M'

Dump after performing the machine dependent reorganisation pass, to `file.28.mach'.

`n'

Dump after register renumbering, to `file.23.rnreg'.

`N'

Dump after the register move pass, to `file.16.regmove'.

`r'

Dump after RTL generation, to `file.00.rtl'.

`R'

Dump after the second instruction scheduling pass, to `file.25.sched2'.

`s'

Dump after CSE (including the jump optimization that sometimes follows CSE), to `file.03.cse'.

`S'

Dump after the first instruction scheduling pass, to `file.17.sched'.

`t'

Dump after the second CSE pass (including the jump optimization that sometimes follows CSE), to `file.10.cse2'.

`w'

Dump after the second flow pass, to `file.21.flow2'.

`X'

Dump after dead code elimination, to `file.06.dce'.

`z'

Dump after the peephole pass, to `file.22.peephole2'.

`a'

Produce all the dumps listed above.

`m'

Print statistics on memory usage, at the end of the run, to standard error.

`p'

Annotate the assembler output with a comment indicating which pattern and alternative was used. The length of each instruction is also printed.

`P'

Dump the RTL in the assembler output as a comment before each instruction. Also turns on `-dp' annotation.

`v'

For each of the other indicated dump files (except for `file.00.rtl'), dump a representation of the control flow graph suitable for viewing with VCG to `file.pass.vcg'.

`x'

Just generate RTL for a function instead of compiling it. Usually used with `r'.

`y'

Dump debugging information during parsing, to standard error.

-fdump-unnumbered

When doing debugging dumps (see `-d' option above), suppress instruction numbers and line number note output. This makes it more feasible to use diff on debugging dumps for compiler invocations with different options, in particular with and without `-g'.

-fdump-translation-unit (C and C++ only)

-fdump-translation-unit-number (C and C++ only)

Dump a representation of the tree structure for the entire translation unit to a file. The file name is made by appending `.tu' to the source file name. If the `-number' form is used, number controls the details of the dump as described for the `-fdump-tree' options.

-fdump-class-hierarchy (C++ only)

-fdump-class-hierarchy-number (C++ only)

Dump a representation of each class's hierarchy and virtual function table layout to a file. The file name is made by appending `.class' to the source file name. If the `-number' form is used, number controls the details of the dump as described for the `-fdump-tree' options.

-fdump-ast-switch (C++ only)

-fdump-ast-switch-number (C++ only)

Control the dumping at various stages of processing the abstract syntax tree to a file. The file name is generated by appending a switch specific suffix to the source file name. If the `-number' form is used, number is a bit mask which controls the details of the dump. The following bits are meaningful (these are not set symbolically, as the primary function of these dumps is for debugging gcc itself):

`bit0 (1)'

Print the address of each node. Usually this is not meaningful as it changes according to the environment and source file.

`bit1 (2)'

Inhibit dumping of members of a scope or body of a function, unless they are reachable by some other path.

The following tree dumps are possible:

`original'

Dump before any tree based optimization, to `file.original'.

`optimized'

Dump after all tree based optimization, to `file.optimized'.

-fpretend-float

When running a cross-compiler, pretend that the target machine uses the same floating point format as the host machine. This causes incorrect output of the actual floating constants, but the actual instruction sequence will probably be the same as GCC would make when running on the target machine.

-save-temps

Store the usual "temporary" intermediate files permanently; place them in the current directory and name them based on the source file. Thus, compiling `foo.c' with `-c -save-temps' would produce files `foo.i' and `foo.s', as well as `foo.o'. This creates a preprocessed `foo.i' output file even though the compiler now normally uses an integrated preprocessor.

-time

Report the CPU time taken by each subprocess in the compilation sequence. For C source files, this is the compiler proper and assembler (plus the linker if linking is done). The output looks like this:

# cc1 0.12 0.01 # as 0.00 0.01

The first number on each line is the "user time," that is time spent executing the program itself. The second number is "system time," time spent executing operating system routines on behalf of the program. Both numbers are in seconds.

-print-file-name=library

Print the full absolute name of the library file library that would be used when linking--and don't do anything else. With this option, GCC does not compile or link anything; it just prints the file name.

-print-multi-directory

Print the directory name corresponding to the multilib selected by any other switches present in the command line. This directory is supposed to exist in GCC_EXEC_PREFIX.

-print-multi-lib

Print the mapping from multilib directory names to compiler switches that enable them. The directory name is separated from the switches by `;', and each switch starts with an `@' instead of the `-', without spaces between multiple switches. This is supposed to ease shell-processing.

-print-prog-name=program

Like `-print-file-name', but searches for a program such as `cpp'.

-print-libgcc-file-name

Same as `-print-file-name=libgcc.a'.

This is useful when you use `-nostdlib' or `-nodefaultlibs' but you do want to link with `libgcc.a'. You can do

gcc -nostdlib files... `gcc -print-libgcc-file-name`

-print-search-dirs

Print the name of the configured installation directory and a list of program and library directories gcc will search--and don't do anything else.

This is useful when gcc prints the error message `installation problem, cannot exec cpp0: No such file or directory'. To resolve this you either need to put `cpp0' and the other compiler components where gcc expects to find them, or you can set the environment variable GCC_EXEC_PREFIX to the directory where you installed them. Don't forget the trailing '/'. See section 3.19 Environment Variables Affecting GCC.

-dumpmachine

Print the compiler's target machine (for example, `i686-pc-linux-gnu')---and don't do anything else.

-dumpversion

Print the compiler version (for example, `3.0')---and don't do anything else.

-dumpspecs

Print the compiler's built-in specs--and don't do anything else. (This is used when GCC itself is being built.) See section 3.15 Specifying subprocesses and the switches to pass to them.