Subversion Repositories openrisc

\input texinfo @c -*-texinfo-*-

@setfilename gprof.info

@c Copyright 1988, 1992, 1993, 1998, 1999, 2000, 2001, 2002, 2003,

@c 2004, 2007, 2008, 2009

@c Free Software Foundation, Inc.

@settitle GNU gprof

@setchapternewpage odd

@c man begin INCLUDE

@include bfdver.texi

@c man end

@ifinfo

@c This is a dir.info fragment to support semi-automated addition of

@c manuals to an info tree.  zoo@cygnus.com is developing this facility.

@format

START-INFO-DIR-ENTRY

* gprof: (gprof).                Profiling your program's execution

END-INFO-DIR-ENTRY

@end format

@end ifinfo

@copying

This file documents the gprof profiler of the GNU system.

@c man begin COPYRIGHT

Copyright @copyright{} 1988, 92, 97, 98, 99, 2000, 2001, 2003, 2007, 2008, 2009 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.3

or any later version published by the Free Software Foundation;

with no Invariant Sections, with no Front-Cover Texts, and with no

Back-Cover Texts.  A copy of the license is included in the

section entitled ``GNU Free Documentation License''.

@c man end

@end copying

@finalout

@smallbook

@titlepage

@title GNU gprof

@subtitle The @sc{gnu} Profiler

@ifset VERSION_PACKAGE

@subtitle @value{VERSION_PACKAGE}

@end ifset

@subtitle Version @value{VERSION}

@author Jay Fenlason and Richard Stallman

@page

This manual describes the @sc{gnu} profiler, @code{gprof}, and how you

can use it to determine which parts of a program are taking most of the

execution time.  We assume that you know how to write, compile, and

execute programs.  @sc{gnu} @code{gprof} was written by Jay Fenlason.

Eric S. Raymond made some minor corrections and additions in 2003.

@vskip 0pt plus 1filll

Copyright @copyright{} 1988, 92, 97, 98, 99, 2000, 2003, 2008, 2009 Free Software Foundation, Inc.

      Permission is granted to copy, distribute and/or modify this document

      under the terms of the GNU Free Documentation License, Version 1.3

      or any later version published by the Free Software Foundation;

      with no Invariant Sections, with no Front-Cover Texts, and with no

      Back-Cover Texts.  A copy of the license is included in the

      section entitled ``GNU Free Documentation License''.

@end titlepage

@contents

@ifnottex

@node Top

@top Profiling a Program: Where Does It Spend Its Time?

This manual describes the @sc{gnu} profiler, @code{gprof}, and how you

can use it to determine which parts of a program are taking most of the

execution time.  We assume that you know how to write, compile, and

execute programs.  @sc{gnu} @code{gprof} was written by Jay Fenlason.

This manual is for @code{gprof}

@ifset VERSION_PACKAGE

@value{VERSION_PACKAGE}

@end ifset

version @value{VERSION}.

This document is distributed under the terms of the GNU Free

Documentation License version 1.3.  A copy of the license is included

in the section entitled ``GNU Free Documentation License''.

@menu

* Introduction::        What profiling means, and why it is useful.

* Compiling::           How to compile your program for profiling.

* Executing::           Executing your program to generate profile data

* Invoking::            How to run @code{gprof}, and its options

* Output::              Interpreting @code{gprof}'s output

* Inaccuracy::          Potential problems you should be aware of

* How do I?::           Answers to common questions

* Incompatibilities::   (between @sc{gnu} @code{gprof} and Unix @code{gprof}.)

* Details::             Details of how profiling is done

* GNU Free Documentation License::  GNU Free Documentation License

@end menu

@end ifnottex

@node Introduction

@chapter Introduction to Profiling

@ifset man

@c man title gprof display call graph profile data

@smallexample

@c man begin SYNOPSIS

gprof [ -[abcDhilLrsTvwxyz] ] [ -[ACeEfFJnNOpPqQZ][@var{name}] ]

 [ -I @var{dirs} ] [ -d[@var{num}] ] [ -k @var{from/to} ]

 [ -m @var{min-count} ] [ -R @var{map_file} ] [ -t @var{table-length} ]

 [ --[no-]annotated-source[=@var{name}] ]

 [ --[no-]exec-counts[=@var{name}] ]

 [ --[no-]flat-profile[=@var{name}] ] [ --[no-]graph[=@var{name}] ]

 [ --[no-]time=@var{name}] [ --all-lines ] [ --brief ]

 [ --debug[=@var{level}] ] [ --function-ordering ]

 [ --file-ordering @var{map_file} ] [ --directory-path=@var{dirs} ]

 [ --display-unused-functions ] [ --file-format=@var{name} ]

 [ --file-info ] [ --help ] [ --line ] [ --min-count=@var{n} ]

 [ --no-static ] [ --print-path ] [ --separate-files ]

 [ --static-call-graph ] [ --sum ] [ --table-length=@var{len} ]

 [ --traditional ] [ --version ] [ --width=@var{n} ]

 [ --ignore-non-functions ] [ --demangle[=@var{STYLE}] ]

 [ --no-demangle ] [--external-symbol-table=name]

 [ @var{image-file} ] [ @var{profile-file} @dots{} ]

@c man end

@end smallexample

@c man begin DESCRIPTION

@code{gprof} produces an execution profile of C, Pascal, or Fortran77

programs.  The effect of called routines is incorporated in the profile

of each caller.  The profile data is taken from the call graph profile file

(@file{gmon.out} default) which is created by programs

that are compiled with the @samp{-pg} option of

@code{cc}, @code{pc}, and @code{f77}.

The @samp{-pg} option also links in versions of the library routines

that are compiled for profiling.  @code{Gprof} reads the given object

file (the default is @code{a.out}) and establishes the relation between

its symbol table and the call graph profile from @file{gmon.out}.

If more than one profile file is specified, the @code{gprof}

output shows the sum of the profile information in the given profile files.

@code{Gprof} calculates the amount of time spent in each routine.

Next, these times are propagated along the edges of the call graph.

Cycles are discovered, and calls into a cycle are made to share the time

of the cycle.

@c man end

@c man begin BUGS

The granularity of the sampling is shown, but remains

statistical at best.

We assume that the time for each execution of a function

can be expressed by the total time for the function divided

by the number of times the function is called.

Thus the time propagated along the call graph arcs to the function's

parents is directly proportional to the number of times that

arc is traversed.

Parents that are not themselves profiled will have the time of

their profiled children propagated to them, but they will appear

to be spontaneously invoked in the call graph listing, and will

not have their time propagated further.

Similarly, signal catchers, even though profiled, will appear

to be spontaneous (although for more obscure reasons).

Any profiled children of signal catchers should have their times

propagated properly, unless the signal catcher was invoked during

the execution of the profiling routine, in which case all is lost.

The profiled program must call @code{exit}(2)

or return normally for the profiling information to be saved

in the @file{gmon.out} file.

@c man end

@c man begin FILES

@table @code

@item @file{a.out}

the namelist and text space.

@item @file{gmon.out}

dynamic call graph and profile.

@item @file{gmon.sum}

summarized dynamic call graph and profile.

@end table

@c man end

@c man begin SEEALSO

monitor(3), profil(2), cc(1), prof(1), and the Info entry for @file{gprof}.

``An Execution Profiler for Modular Programs'',

by S. Graham, P. Kessler, M. McKusick;

Software - Practice and Experience,

Vol. 13, pp. 671-685, 1983.

``gprof: A Call Graph Execution Profiler'',

by S. Graham, P. Kessler, M. McKusick;

Proceedings of the SIGPLAN '82 Symposium on Compiler Construction,

SIGPLAN Notices, Vol. 17, No  6, pp. 120-126, June 1982.

@c man end

@end ifset

Profiling allows you to learn where your program spent its time and which

functions called which other functions while it was executing.  This

information can show you which pieces of your program are slower than you

expected, and might be candidates for rewriting to make your program

execute faster.  It can also tell you which functions are being called more

or less often than you expected.  This may help you spot bugs that had

otherwise been unnoticed.

Since the profiler uses information collected during the actual execution

of your program, it can be used on programs that are too large or too

complex to analyze by reading the source.  However, how your program is run

will affect the information that shows up in the profile data.  If you

don't use some feature of your program while it is being profiled, no

profile information will be generated for that feature.

Profiling has several steps:

@itemize @bullet

@item

You must compile and link your program with profiling enabled.

@xref{Compiling, ,Compiling a Program for Profiling}.

@item

You must execute your program to generate a profile data file.

@xref{Executing, ,Executing the Program}.

@item

You must run @code{gprof} to analyze the profile data.

@xref{Invoking, ,@code{gprof} Command Summary}.

@end itemize

The next three chapters explain these steps in greater detail.

@c man begin DESCRIPTION

Several forms of output are available from the analysis.

The @dfn{flat profile} shows how much time your program spent in each function,

and how many times that function was called.  If you simply want to know

which functions burn most of the cycles, it is stated concisely here.

@xref{Flat Profile, ,The Flat Profile}.

The @dfn{call graph} shows, for each function, which functions called it, which

other functions it called, and how many times.  There is also an estimate

of how much time was spent in the subroutines of each function.  This can

suggest places where you might try to eliminate function calls that use a

lot of time.  @xref{Call Graph, ,The Call Graph}.

The @dfn{annotated source} listing is a copy of the program's

source code, labeled with the number of times each line of the

program was executed.  @xref{Annotated Source, ,The Annotated Source

Listing}.

@c man end

To better understand how profiling works, you may wish to read

a description of its implementation.

@xref{Implementation, ,Implementation of Profiling}.

@node Compiling

@chapter Compiling a Program for Profiling

The first step in generating profile information for your program is

to compile and link it with profiling enabled.

To compile a source file for profiling, specify the @samp{-pg} option when

you run the compiler.  (This is in addition to the options you normally

use.)

To link the program for profiling, if you use a compiler such as @code{cc}

to do the linking, simply specify @samp{-pg} in addition to your usual

options.  The same option, @samp{-pg}, alters either compilation or linking

to do what is necessary for profiling.  Here are examples:

@example

cc -g -c myprog.c utils.c -pg

cc -o myprog myprog.o utils.o -pg

@end example

The @samp{-pg} option also works with a command that both compiles and links:

@example

cc -o myprog myprog.c utils.c -g -pg

@end example

Note: The @samp{-pg} option must be part of your compilation options

as well as your link options.  If it is not then no call-graph data

will be gathered and when you run @code{gprof} you will get an error

message like this:

@example

gprof: gmon.out file is missing call-graph data

@end example

If you add the @samp{-Q} switch to suppress the printing of the call

graph data you will still be able to see the time samples:

@example

Flat profile:

Each sample counts as 0.01 seconds.

  %   cumulative   self              self     total

 time   seconds   seconds    calls  Ts/call  Ts/call  name

 44.12      0.07     0.07                             zazLoop

 35.29      0.14     0.06                             main

 20.59      0.17     0.04                             bazMillion

@end example

If you run the linker @code{ld} directly instead of through a compiler

such as @code{cc}, you may have to specify a profiling startup file

@file{gcrt0.o} as the first input file instead of the usual startup

file @file{crt0.o}.  In addition, you would probably want to

specify the profiling C library, @file{libc_p.a}, by writing

@samp{-lc_p} instead of the usual @samp{-lc}.  This is not absolutely

necessary, but doing this gives you number-of-calls information for

standard library functions such as @code{read} and @code{open}.  For

example:

@example

ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p

@end example

If you are running the program on a system which supports shared

libraries you may run into problems with the profiling support code in

a shared library being called before that library has been fully

initialised.  This is usually detected by the program encountering a

segmentation fault as soon as it is run.  The solution is to link

against a static version of the library containing the profiling

support code, which for @code{gcc} users can be done via the

@samp{-static} or @samp{-static-libgcc} command line option.  For

example:

@example

gcc -g -pg -static-libgcc myprog.c utils.c -o myprog

@end example

If you compile only some of the modules of the program with @samp{-pg}, you

can still profile the program, but you won't get complete information about

the modules that were compiled without @samp{-pg}.  The only information

you get for the functions in those modules is the total time spent in them;

there is no record of how many times they were called, or from where.  This

will not affect the flat profile (except that the @code{calls} field for

the functions will be blank), but will greatly reduce the usefulness of the

call graph.

If you wish to perform line-by-line profiling you should use the

@code{gcov} tool instead of @code{gprof}.  See that tool's manual or

info pages for more details of how to do this.

Note, older versions of @code{gcc} produce line-by-line profiling

information that works with @code{gprof} rather than @code{gcov} so

there is still support for displaying this kind of information in

@code{gprof}. @xref{Line-by-line, ,Line-by-line Profiling}.

It also worth noting that @code{gcc} implements a

@samp{-finstrument-functions} command line option which will insert

calls to special user supplied instrumentation routines at the entry

and exit of every function in their program.  This can be used to

implement an alternative profiling scheme.

@node Executing

@chapter Executing the Program

Once the program is compiled for profiling, you must run it in order to

generate the information that @code{gprof} needs.  Simply run the program

as usual, using the normal arguments, file names, etc.  The program should

run normally, producing the same output as usual.  It will, however, run

somewhat slower than normal because of the time spent collecting and

writing the profile data.

The way you run the program---the arguments and input that you give

it---may have a dramatic effect on what the profile information shows.  The

profile data will describe the parts of the program that were activated for

the particular input you use.  For example, if the first command you give

to your program is to quit, the profile data will show the time used in

initialization and in cleanup, but not much else.

Your program will write the profile data into a file called @file{gmon.out}

just before exiting.  If there is already a file called @file{gmon.out},

its contents are overwritten.  There is currently no way to tell the

program to write the profile data under a different name, but you can rename

the file afterwards if you are concerned that it may be overwritten.

In order to write the @file{gmon.out} file properly, your program must exit

normally: by returning from @code{main} or by calling @code{exit}.  Calling

the low-level function @code{_exit} does not write the profile data, and

neither does abnormal termination due to an unhandled signal.

The @file{gmon.out} file is written in the program's @emph{current working

directory} at the time it exits.  This means that if your program calls

@code{chdir}, the @file{gmon.out} file will be left in the last directory

your program @code{chdir}'d to.  If you don't have permission to write in

this directory, the file is not written, and you will get an error message.

Older versions of the @sc{gnu} profiling library may also write a file

called @file{bb.out}.  This file, if present, contains an human-readable

listing of the basic-block execution counts.  Unfortunately, the

appearance of a human-readable @file{bb.out} means the basic-block

counts didn't get written into @file{gmon.out}.

The Perl script @code{bbconv.pl}, included with the @code{gprof}

source distribution, will convert a @file{bb.out} file into

a format readable by @code{gprof}.  Invoke it like this:

@smallexample

bbconv.pl < bb.out > @var{bh-data}

@end smallexample

This translates the information in @file{bb.out} into a form that

@code{gprof} can understand.  But you still need to tell @code{gprof}

about the existence of this translated information.  To do that, include

@var{bb-data} on the @code{gprof} command line, @emph{along with

@file{gmon.out}}, like this:

@smallexample

gprof @var{options} @var{executable-file} gmon.out @var{bb-data} [@var{yet-more-profile-data-files}@dots{}] [> @var{outfile}]

@end smallexample

@node Invoking

@chapter @code{gprof} Command Summary

After you have a profile data file @file{gmon.out}, you can run @code{gprof}

to interpret the information in it.  The @code{gprof} program prints a

flat profile and a call graph on standard output.  Typically you would

redirect the output of @code{gprof} into a file with @samp{>}.

You run @code{gprof} like this:

@smallexample

gprof @var{options} [@var{executable-file} [@var{profile-data-files}@dots{}]] [> @var{outfile}]

@end smallexample

@noindent

Here square-brackets indicate optional arguments.

If you omit the executable file name, the file @file{a.out} is used.  If

you give no profile data file name, the file @file{gmon.out} is used.  If

any file is not in the proper format, or if the profile data file does not

appear to belong to the executable file, an error message is printed.

You can give more than one profile data file by entering all their names

after the executable file name; then the statistics in all the data files

are summed together.

The order of these options does not matter.

@menu

* Output Options::      Controlling @code{gprof}'s output style

* Analysis Options::    Controlling how @code{gprof} analyzes its data

* Miscellaneous Options::

* Deprecated Options::  Options you no longer need to use, but which

                            have been retained for compatibility

* Symspecs::            Specifying functions to include or exclude

@end menu

@node Output Options

@section Output Options

@c man begin OPTIONS

These options specify which of several output formats

@code{gprof} should produce.

Many of these options take an optional @dfn{symspec} to specify

functions to be included or excluded.  These options can be

specified multiple times, with different symspecs, to include

or exclude sets of symbols.  @xref{Symspecs, ,Symspecs}.

Specifying any of these options overrides the default (@samp{-p -q}),

which prints a flat profile and call graph analysis

for all functions.

@table @code

@item -A[@var{symspec}]

@itemx --annotated-source[=@var{symspec}]

The @samp{-A} option causes @code{gprof} to print annotated source code.

If @var{symspec} is specified, print output only for matching symbols.

@xref{Annotated Source, ,The Annotated Source Listing}.

@item -b

@itemx --brief

If the @samp{-b} option is given, @code{gprof} doesn't print the

verbose blurbs that try to explain the meaning of all of the fields in

the tables.  This is useful if you intend to print out the output, or

are tired of seeing the blurbs.

@item -C[@var{symspec}]

@itemx --exec-counts[=@var{symspec}]

The @samp{-C} option causes @code{gprof} to

print a tally of functions and the number of times each was called.

If @var{symspec} is specified, print tally only for matching symbols.

If the profile data file contains basic-block count records, specifying

the @samp{-l} option, along with @samp{-C}, will cause basic-block

execution counts to be tallied and displayed.

@item -i

@itemx --file-info

The @samp{-i} option causes @code{gprof} to display summary information

about the profile data file(s) and then exit.  The number of histogram,

call graph, and basic-block count records is displayed.

@item -I @var{dirs}

@itemx --directory-path=@var{dirs}

The @samp{-I} option specifies a list of search directories in

which to find source files.  Environment variable @var{GPROF_PATH}

can also be used to convey this information.

Used mostly for annotated source output.

@item -J[@var{symspec}]

@itemx --no-annotated-source[=@var{symspec}]

The @samp{-J} option causes @code{gprof} not to

print annotated source code.

If @var{symspec} is specified, @code{gprof} prints annotated source,

but excludes matching symbols.

@item -L

@itemx --print-path

Normally, source filenames are printed with the path

component suppressed.  The @samp{-L} option causes @code{gprof}

to print the full pathname of

source filenames, which is determined

from symbolic debugging information in the image file

and is relative to the directory in which the compiler

was invoked.

@item -p[@var{symspec}]

@itemx --flat-profile[=@var{symspec}]

The @samp{-p} option causes @code{gprof} to print a flat profile.

If @var{symspec} is specified, print flat profile only for matching symbols.

@xref{Flat Profile, ,The Flat Profile}.

@item -P[@var{symspec}]

@itemx --no-flat-profile[=@var{symspec}]

The @samp{-P} option causes @code{gprof} to suppress printing a flat profile.

If @var{symspec} is specified, @code{gprof} prints a flat profile,

but excludes matching symbols.

@item -q[@var{symspec}]

@itemx --graph[=@var{symspec}]

The @samp{-q} option causes @code{gprof} to print the call graph analysis.

If @var{symspec} is specified, print call graph only for matching symbols

and their children.

@xref{Call Graph, ,The Call Graph}.

@item -Q[@var{symspec}]

@itemx --no-graph[=@var{symspec}]

The @samp{-Q} option causes @code{gprof} to suppress printing the

call graph.

If @var{symspec} is specified, @code{gprof} prints a call graph,

but excludes matching symbols.

@item -t

@itemx --table-length=@var{num}

The @samp{-t} option causes the @var{num} most active source lines in

each source file to be listed when source annotation is enabled.  The

default is 10.

@item -y

@itemx --separate-files

This option affects annotated source output only.

Normally, @code{gprof} prints annotated source files

to standard-output.  If this option is specified,

annotated source for a file named @file{path/@var{filename}}

is generated in the file @file{@var{filename}-ann}.  If the underlying

file system would truncate @file{@var{filename}-ann} so that it

overwrites the original @file{@var{filename}}, @code{gprof} generates

annotated source in the file @file{@var{filename}.ann} instead (if the

original file name has an extension, that extension is @emph{replaced}

with @file{.ann}).

@item -Z[@var{symspec}]

@itemx --no-exec-counts[=@var{symspec}]

The @samp{-Z} option causes @code{gprof} not to

print a tally of functions and the number of times each was called.

If @var{symspec} is specified, print tally, but exclude matching symbols.

@item -r

@itemx --function-ordering

The @samp{--function-ordering} option causes @code{gprof} to print a

suggested function ordering for the program based on profiling data.

This option suggests an ordering which may improve paging, tlb and

cache behavior for the program on systems which support arbitrary

ordering of functions in an executable.

The exact details of how to force the linker to place functions

in a particular order is system dependent and out of the scope of this

manual.

@item -R @var{map_file}

@itemx --file-ordering @var{map_file}

The @samp{--file-ordering} option causes @code{gprof} to print a

suggested .o link line ordering for the program based on profiling data.

This option suggests an ordering which may improve paging, tlb and

cache behavior for the program on systems which do not support arbitrary

ordering of functions in an executable.

Use of the @samp{-a} argument is highly recommended with this option.

The @var{map_file} argument is a pathname to a file which provides

function name to object file mappings.  The format of the file is similar to

the output of the program @code{nm}.

@smallexample

@group

c-parse.o:00000000 T yyparse

c-parse.o:00000004 C yyerrflag

c-lang.o:00000000 T maybe_objc_method_name

c-lang.o:00000000 T print_lang_statistics

c-lang.o:00000000 T recognize_objc_keyword

c-decl.o:00000000 T print_lang_identifier

c-decl.o:00000000 T print_lang_type

@dots{}

@end group

@end smallexample

To create a @var{map_file} with @sc{gnu} @code{nm}, type a command like

@kbd{nm --extern-only --defined-only -v --print-file-name program-name}.

@item -T

@itemx --traditional

The @samp{-T} option causes @code{gprof} to print its output in

``traditional'' BSD style.

@item -w @var{width}

@itemx --width=@var{width}

Sets width of output lines to @var{width}.

Currently only used when printing the function index at the bottom

of the call graph.

@item -x

@itemx --all-lines

This option affects annotated source output only.

By default, only the lines at the beginning of a basic-block

are annotated.  If this option is specified, every line in

a basic-block is annotated by repeating the annotation for the

first line.  This behavior is similar to @code{tcov}'s @samp{-a}.

@item --demangle[=@var{style}]

@itemx --no-demangle

These options control whether C++ symbol names should be demangled when

printing output.  The default is to demangle symbols.  The

@code{--no-demangle} option may be used to turn off demangling. Different

compilers have different mangling styles.  The optional demangling style

argument can be used to choose an appropriate demangling style for your

compiler.

@end table

@node Analysis Options

@section Analysis Options

@table @code

@item -a

@itemx --no-static

The @samp{-a} option causes @code{gprof} to suppress the printing of

statically declared (private) functions.  (These are functions whose

names are not listed as global, and which are not visible outside the

file/function/block where they were defined.)  Time spent in these

functions, calls to/from them, etc., will all be attributed to the

function that was loaded directly before it in the executable file.

@c This is compatible with Unix @code{gprof}, but a bad idea.

This option affects both the flat profile and the call graph.

@item -c

@itemx --static-call-graph

The @samp{-c} option causes the call graph of the program to be

augmented by a heuristic which examines the text space of the object

file and identifies function calls in the binary machine code.

Since normal call graph records are only generated when functions are

entered, this option identifies children that could have been called,

but never were.  Calls to functions that were not compiled with

profiling enabled are also identified, but only if symbol table

entries are present for them.

Calls to dynamic library routines are typically @emph{not} found

by this option.

Parents or children identified via this heuristic

are indicated in the call graph with call counts of @samp{0}.

@item -D

@itemx --ignore-non-functions

The @samp{-D} option causes @code{gprof} to ignore symbols which

are not known to be functions.  This option will give more accurate

profile data on systems where it is supported (Solaris and HPUX for

example).

@item -k @var{from}/@var{to}

The @samp{-k} option allows you to delete from the call graph any arcs from

symbols matching symspec @var{from} to those matching symspec @var{to}.

@item -l

@itemx --line

The @samp{-l} option enables line-by-line profiling, which causes

histogram hits to be charged to individual source code lines,

instead of functions.  This feature only works with programs compiled

by older versions of the @code{gcc} compiler.  Newer versions of

@code{gcc} are designed to work with the @code{gcov} tool instead.

If the program was compiled with basic-block counting enabled,

this option will also identify how many times each line of

code was executed.

While line-by-line profiling can help isolate where in a large function

a program is spending its time, it also significantly increases

the running time of @code{gprof}, and magnifies statistical

inaccuracies.

@xref{Sampling Error, ,Statistical Sampling Error}.

@item -m @var{num}

@itemx --min-count=@var{num}

This option affects execution count output only.

Symbols that are executed less than @var{num} times are suppressed.

@item -n@var{symspec}

@itemx --time=@var{symspec}

The @samp{-n} option causes @code{gprof}, in its call graph analysis,

to only propagate times for symbols matching @var{symspec}.

@item -N@var{symspec}

@itemx --no-time=@var{symspec}

The @samp{-n} option causes @code{gprof}, in its call graph analysis,

not to propagate times for symbols matching @var{symspec}.

@item -S@var{filename}

@itemx --external-symbol-table=@var{filename}

The @samp{-S} option causes @code{gprof} to read an external symbol table

file, such as @file{/proc/kallsyms}, rather than read the symbol table

from the given object file (the default is @code{a.out}). This is useful

for profiling kernel modules.

@item -z

@itemx --display-unused-functions

If you give the @samp{-z} option, @code{gprof} will mention all

functions in the flat profile, even those that were never called, and

that had no time spent in them.  This is useful in conjunction with the

@samp{-c} option for discovering which routines were never called.

@end table

@node Miscellaneous Options

@section Miscellaneous Options

@table @code

@item -d[@var{num}]

@itemx --debug[=@var{num}]

The @samp{-d @var{num}} option specifies debugging options.

If @var{num} is not specified, enable all debugging.

@xref{Debugging, ,Debugging @code{gprof}}.

@item -h

@itemx --help

The @samp{-h} option prints command line usage.

@item -O@var{name}

@itemx --file-format=@var{name}

Selects the format of the profile data files.  Recognized formats are

@samp{auto} (the default), @samp{bsd}, @samp{4.4bsd}, @samp{magic}, and

@samp{prof} (not yet supported).

@item -s

@itemx --sum

The @samp{-s} option causes @code{gprof} to summarize the information

in the profile data files it read in, and write out a profile data

file called @file{gmon.sum}, which contains all the information from

the profile data files that @code{gprof} read in.  The file @file{gmon.sum}

may be one of the specified input files; the effect of this is to

merge the data in the other input files into @file{gmon.sum}.

Eventually you can run @code{gprof} again without @samp{-s} to analyze the

cumulative data in the file @file{gmon.sum}.

@item -v

@itemx --version

The @samp{-v} flag causes @code{gprof} to print the current version

number, and then exit.

@end table

@node Deprecated Options

@section Deprecated Options

@table @code

These options have been replaced with newer versions that use symspecs.

@item -e @var{function_name}

The @samp{-e @var{function}} option tells @code{gprof} to not print

information about the function @var{function_name} (and its

children@dots{}) in the call graph.  The function will still be listed

as a child of any functions that call it, but its index number will be

shown as @samp{[not printed]}.  More than one @samp{-e} option may be

given; only one @var{function_name} may be indicated with each @samp{-e}

option.

@item -E @var{function_name}

The @code{-E @var{function}} option works like the @code{-e} option, but

time spent in the function (and children who were not called from

anywhere else), will not be used to compute the percentages-of-time for

the call graph.  More than one @samp{-E} option may be given; only one

@var{function_name} may be indicated with each @samp{-E} option.

@item -f @var{function_name}

The @samp{-f @var{function}} option causes @code{gprof} to limit the

call graph to the function @var{function_name} and its children (and

their children@dots{}).  More than one @samp{-f} option may be given;

only one @var{function_name} may be indicated with each @samp{-f}

option.

@item -F @var{function_name}

The @samp{-F @var{function}} option works like the @code{-f} option, but

only time spent in the function and its children (and their

children@dots{}) will be used to determine total-time and

percentages-of-time for the call graph.  More than one @samp{-F} option

may be given; only one @var{function_name} may be indicated with each

@samp{-F} option.  The @samp{-F} option overrides the @samp{-E} option.

@end table

@c man end

Note that only one function can be specified with each @code{-e},

@code{-E}, @code{-f} or @code{-F} option.  To specify more than one

function, use multiple options.  For example, this command:

@example

gprof -e boring -f foo -f bar myprogram > gprof.output

@end example

@noindent

lists in the call graph all functions that were reached from either

@code{foo} or @code{bar} and were not reachable from @code{boring}.

@node Symspecs

@section Symspecs

Many of the output options allow functions to be included or excluded

using @dfn{symspecs} (symbol specifications), which observe the

following syntax:

@example

  filename_containing_a_dot

| funcname_not_containing_a_dot

| linenumber

| ( [ any_filename ] `:' ( any_funcname | linenumber ) )

@end example

Here are some sample symspecs:

@table @samp

@item main.c

Selects everything in file @file{main.c}---the

dot in the string tells @code{gprof} to interpret

the string as a filename, rather than as

a function name.  To select a file whose

name does not contain a dot, a trailing colon

should be specified.  For example, @samp{odd:} is

interpreted as the file named @file{odd}.

@item main

Selects all functions named @samp{main}.

Note that there may be multiple instances of the same function name

because some of the definitions may be local (i.e., static).  Unless a

function name is unique in a program, you must use the colon notation

explained below to specify a function from a specific source file.

Sometimes, function names contain dots.  In such cases, it is necessary

to add a leading colon to the name.  For example, @samp{:.mul} selects

function @samp{.mul}.

In some object file formats, symbols have a leading underscore.

@code{gprof} will normally not print these underscores.  When you name a

symbol in a symspec, you should type it exactly as @code{gprof} prints

it in its output.  For example, if the compiler produces a symbol

@samp{_main} from your @code{main} function, @code{gprof} still prints

it as @samp{main} in its output, so you should use @samp{main} in

symspecs.

@item main.c:main

Selects function @samp{main} in file @file{main.c}.

@item main.c:134

Selects line 134 in file @file{main.c}.

@end table

@node Output

@chapter Interpreting @code{gprof}'s Output

@code{gprof} can produce several different output styles, the

most important of which are described below.  The simplest output

styles (file information, execution count, and function and file ordering)

are not described here, but are documented with the respective options

that trigger them.

@xref{Output Options, ,Output Options}.

@menu

* Flat Profile::        The flat profile shows how much time was spent

                            executing directly in each function.

* Call Graph::          The call graph shows which functions called which

                            others, and how much time each function used

                            when its subroutine calls are included.

* Line-by-line::        @code{gprof} can analyze individual source code lines

* Annotated Source::    The annotated source listing displays source code

                            labeled with execution counts

@end menu

@node Flat Profile

@section The Flat Profile

@cindex flat profile

The @dfn{flat profile} shows the total amount of time your program

spent executing each function.  Unless the @samp{-z} option is given,

functions with no apparent time spent in them, and no apparent calls

to them, are not mentioned.  Note that if a function was not compiled

for profiling, and didn't run long enough to show up on the program

counter histogram, it will be indistinguishable from a function that

was never called.

This is part of a flat profile for a small program:

@smallexample

@group

Flat profile:

Each sample counts as 0.01 seconds.

  %   cumulative   self              self     total

 time   seconds   seconds    calls  ms/call  ms/call  name

 33.34      0.02     0.02     7208     0.00     0.00  open

 16.67      0.03     0.01      244     0.04     0.12  offtime

 16.67      0.04     0.01        8     1.25     1.25  memccpy

 16.67      0.05     0.01        7     1.43     1.43  write

 16.67      0.06     0.01                             mcount