GPROF(1) User Commands GPROF(1)

NAME

gprof - display call-graph profile data

SYNOPSIS

gprof [-abcCDlsz] [-e function-name] [-E function-name]
[-f function-name] [-F function-name]
[image-file [profile-file...]]
[-n number of functions]

DESCRIPTION

The gprof utility produces an execution profile of a program. The effect
of called routines is incorporated in the profile of each caller. The
profile data is taken from the call graph profile file that is created by
programs compiled with the -xpg option of cc(1), or by the -pg option
with other compilers, or by setting the LD_PROFILE environment variable
for shared objects. See ld.so.1(1). These compiler options also link in
versions of the library routines which are compiled for profiling. The
symbol table in the executable image file image-file (a.out by default)
is read and correlated with the call graph profile file profile-file
(gmon.out by default).


First, execution times for each routine 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. The first listing shows the functions
sorted according to the time they represent, including the time of their
call graph descendants. Below each function entry is shown its (direct)
call-graph children and how their times are propagated to this function.
A similar display above the function shows how this function's time and
the time of its descendants are propagated to its (direct) call-graph
parents.


Cycles are also shown, with an entry for the cycle as a whole and a
listing of the members of the cycle and their contributions to the time
and call counts of the cycle.


Next, a flat profile is given. This listing gives the total execution
times and call counts for each of the functions in the program, sorted by
decreasing time. Finally, an index is given, which shows the
correspondence between function names and call-graph profile index
numbers.


A single function may be split into subfunctions for profiling by means
of the MARK macro. See prof(7).


Beware of quantization errors. The granularity of the sampling is shown,
but remains statistical at best. It is assumed 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 parents of that function is
directly proportional to the number of times that arc is traversed.


The profiled program must call exit(2) or return normally for the
profiling information to be saved in the gmon.out file.

OPTIONS

The following options are supported:

-a
Suppress printing statically declared functions. If
this option is given, all relevant information about
the static function (for instance, time samples, calls
to other functions, calls from other functions)
belongs to the function loaded just before the static
function in the a.out file.


-b
Brief. Suppress descriptions of each field in the
profile.


-c
Discover the static call-graph of the program by a
heuristic which examines the text space of the object
file. Static-only parents or children are indicated
with call counts of 0. Note that for dynamically
linked executables, the linked shared objects' text
segments are not examined.


-C
Demangle symbol names before printing them out.


-D
Produce a profile file gmon.sum that represents the
difference of the profile information in all specified
profile files. This summary profile file may be given
to subsequent executions of gprof (also with -D) to
summarize profile data across several runs of an a.out
file. See also the -s option.

As an example, suppose function A calls function B n
times in profile file gmon.sum, and m times in profile
file gmon.out. With -D, a new gmon.sum file will be
created showing the number of calls from A to B as n-
m.


-efunction-name
Suppress printing the graph profile entry for routine
function-name and all its descendants (unless they
have other ancestors that are not suppressed). More
than one -e option may be given. Only one function-
name may be given with each -e option.


-Efunction-name
Suppress printing the graph profile entry for routine
function-name (and its descendants) as -e, below, and
also exclude the time spent in function-name (and its
descendants) from the total and percentage time
computations. More than one -E option may be given.
For example:

-E mcount -E mcleanup

is the default.


-ffunction-name
Print the graph profile entry only for routine
function-name and its descendants. More than one -f
option may be given. Only one function-name may be
given with each -f option.


-Ffunction-name
Print the graph profile entry only for routine
function-name and its descendants (as -f, below) and
also use only the times of the printed routines in
total time and percentage computations. More than one
-F option may be given. Only one function-name may be
given with each -F option. The -F option overrides
the -E option.


-l
Suppress the reporting of graph profile entries for
all local symbols. This option would be the
equivalent of placing all of the local symbols for the
specified executable image on the -E exclusion list.


-n
Limits the size of flat and graph profile listings to
the top n offending functions.


-s
Produce a profile file gmon.sum which represents the
sum of the profile information in all of the specified
profile files. This summary profile file may be given
to subsequent executions of gprof (also with -s) to
accumulate profile data across several runs of an
a.out file. See also the -D option.


-z
Display routines which have zero usage (as indicated
by call counts and accumulated time). This is useful
in conjunction with the -c option for discovering
which routines were never called. Note that this has
restricted use for dynamically linked executables,
since shared object text space will not be examined by
the -c option.

ENVIRONMENT VARIABLES

PROFDIR
If this environment variable contains a value, place profiling
output within that directory, in a file named pid.programname.
pid is the process ID and programname is the name of the
program being profiled, as determined by removing any path
prefix from the argv[0] with which the program was called. If
the variable contains a null value, no profiling output is
produced. Otherwise, profiling output is placed in the file
gmon.out.

FILES

a.out
executable file containing namelist


gmon.out
dynamic call-graph and profile


gmon.sum
summarized dynamic call-graph and profile


$PROFDIR/pid.programname

SEE ALSO

cc(1), ld.so.1(1), exit(2), pcsample(2), profil(2), malloc(3C),
monitor(3C), malloc(3MALLOC), attributes(7), prof(7)


Graham, S.L., Kessler, P.B., McKusick, M.K., gprof: A Call Graph
Execution Profiler Proceedings of the SIGPLAN '82 Symposium on Compiler
Construction, SIGPLAN Notices, Vol. 17, No. 6, pp. 120-126, June 1982.


Linker and Libraries Guide

NOTES

If the executable image has been stripped and does not have the .symtab
symbol table, gprof reads the global dynamic symbol tables .dynsym and
.SUNW_ldynsym, if present. The symbols in the dynamic symbol tables are
a subset of the symbols that are found in .symtab. The .dynsym symbol
table contains the global symbols used by the runtime linker.
.SUNW_ldynsym augments the information in .dynsym with local function
symbols. In the case where .dynsym is found and .SUNW_ldynsym is not,
only the information for the global symbols is available. Without local
symbols, the behavior is as described for the -a option.


LD_LIBRARY_PATH must not contain /usr/lib as a component when compiling a
program for profiling. If LD_LIBRARY_PATH contains /usr/lib, the
program will not be linked correctly with the profiling versions of the
system libraries in /usr/lib/libp.


The times reported in successive identical runs may show variances
because of varying cache-hit ratios that result from sharing the cache
with other processes. Even if a program seems to be the only one using
the machine, hidden background or asynchronous processes may blur the
data. In rare cases, the clock ticks initiating recording of the program
counter may beat with loops in a program, grossly distorting
measurements. Call counts are always recorded precisely, however.


Only programs that call exit or return from main are guaranteed to
produce a profile file, unless a final call to monitor is explicitly
coded.


Functions such as mcount(), _mcount(), moncontrol(), _moncontrol(),
monitor(), and _monitor() may appear in the gprof report. These
functions are part of the profiling implementation and thus account for
some amount of the runtime overhead. Since these functions are not
present in an unprofiled application, time accumulated and call counts
for these functions may be ignored when evaluating the performance of an
application.

64-bit profiling
64-bit profiling may be used freely with dynamically linked executables,
and profiling information is collected for the shared objects if the
objects are compiled for profiling. Care must be applied to interpret the
profile output, since it is possible for symbols from different shared
objects to have the same name. If name duplication occurs in the profile
output, the module id prefix before the symbol name in the symbol index
listing can be used to identify the appropriate module for the symbol.


When using the -s or -Doption to sum multiple profile files, care must be
taken not to mix 32-bit profile files with 64-bit profile files.

32-bit profiling
32-bit profiling may be used with dynamically linked executables, but
care must be applied. In 32-bit profiling, shared objects cannot be
profiled with gprof. Thus, when a profiled, dynamically linked program is
executed, only the main portion of the image is sampled. This means that
all time spent outside of the main object, that is, time spent in a
shared object, will not be included in the profile summary; the total
time reported for the program may be less than the total time used by the
program.


Because the time spent in a shared object cannot be accounted for, the
use of shared objects should be minimized whenever a program is profiled
with gprof. If desired, the program should be linked to the profiled
version of a library (or to the standard archive version if no profiling
version is available), instead of the shared object to get profile
information on the functions of a library. Versions of profiled libraries
may be supplied with the system in the /usr/lib/libp directory. Refer to
compiler driver documentation on profiling.


Consider an extreme case. A profiled program dynamically linked with the
shared C library spends 100 units of time in some libc routine, say,
malloc(). Suppose malloc() is called only from routine B and B consumes
only 1 unit of time. Suppose further that routine A consumes 10 units of
time, more than any other routine in the main (profiled) portion of the
image. In this case, gprof will conclude that most of the time is being
spent in A and almost no time is being spent in B. From this it will be
almost impossible to tell that the greatest improvement can be made by
looking at routine B and not routine A. The value of the profiler in
this case is severely degraded; the solution is to use archives as much
as possible for profiling.

BUGS

Parents which 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.


April 10, 2023 GPROF(1)