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.
`-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' (*note Options that Control Optimization:
Optimize Options.) when recompiling, to optimize using estimated
branch probabilities.
`-ftest-coverage'
Create data files for the `gcov' code-coverage utility (Note:`gcov'.). 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').
`-Q'
Makes the compiler print out each function name as it is compiled,
and print some statistics about each pass when it finishes.
`-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 word to the
source file name (e.g. `foo.c.rtl' or `foo.c.jump'). Here are the
possible letters for use in LETTERS, and their meanings:
`b'
Dump after computing branch probabilities, to `FILE.bp'.
`c'
Dump after instruction combination, to the file
`FILE.combine'.
`d'
Dump after delayed branch scheduling, to `FILE.dbr'.
`D'
Dump all macro definitions, at the end of preprocessing, in
addition to normal output.
`r'
Dump after RTL generation, to `FILE.rtl'.
`j'
Dump after first jump optimization, to `FILE.jump'.
`F'
Dump after purging ADDRESSOF, to `FILE.addressof'.
`f'
Dump after flow analysis, to `FILE.flow'.
`g'
Dump after global register allocation, to `FILE.greg'.
`G'
Dump after GCSE, to `FILE.gcse'.
`j'
Dump after first jump optimization, to `FILE.jump'.
`J'
Dump after last jump optimization, to `FILE.jump2'.
`k'
Dump after conversion from registers to stack, to
`FILE.stack'.
`l'
Dump after local register allocation, to `FILE.lreg'.
`L'
Dump after loop optimization, to `FILE.loop'.
`M'
Dump after performing the machine dependent reorganisation
pass, to `FILE.mach'.
`N'
Dump after the register move pass, to `FILE.regmove'.
`r'
Dump after RTL generation, to `FILE.rtl'.
`R'
Dump after the second instruction scheduling pass, to
`FILE.sched2'.
`s'
Dump after CSE (including the jump optimization that
sometimes follows CSE), to `FILE.cse'.
`S'
Dump after the first instruction scheduling pass, to
`FILE.sched'.
`t'
Dump after the second CSE pass (including the jump
optimization that sometimes follows CSE), to `FILE.cse2'.
`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.
`x'
Just generate RTL for a function instead of compiling it.
Usually used with `r'.
`y'
Dump debugging information during parsing, to standard error.
`A'
Annotate the assembler output with miscellaneous debugging
information.
`-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
invokations with different options, in particular with and without
-g.
`-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'.
`-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-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 cpp: No such file or directory'. To resolve
this you either need to put `cpp' 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 '/'. Note:Environment
Variables.