gprof(1) gprof(1)
NAME [Toc] [Back]
gprof - display call graph profile data
SYNOPSIS [Toc] [Back]
gprof [options] [a.out [gmon.out...]]
DESCRIPTION [Toc] [Back]
The gprof command produces an execution profile of C++, C and FORTRAN
programs. The effect of called routines is incorporated into the
profile of each caller. Profile data is taken from the call graph
profile file (gmon.out default) that is created by programs compiled
with the -G option of aCC, cc, and f90. The -G option also links in
versions of the library routines that are compiled for profiling.
On Itanium(R)-based systems, gprof supports multiple shared libraries
profiling. On PA-RISC systems, gprof supports single shared library
profiling. For details on this see the section below, Shared Library
Profiling.
The symbol table for the load modules being profiled are read and
correlated with the call graph profile file (gmon.out). To have the
full call graph, no load module symbol table may be chopped; that is,
no compiles may use the -x option. If more than one profile file is
specified, gprof output shows the sum of the profile information in
the given profile files.
First, a flat profile is given, similar to that provided by prof (see
prof(1)). This listing gives the total execution times and call
counts for each function in the load modules being profiled, sorted by
decreasing time. On Itanium-based systems, the module index is also
reported for each function signifying the load module in which the
function is defined.
Next, these times are propagated along the edges of the call graph.
gprof discovers all cycles in the call graph. All calls made into the
cycle share the time of that cycle. A second 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 the time of this function 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, each with their contributions to
the time and call counts of the cycle.
On Itanium-based systems, in the end a mapping of all module indices
to module names is given. The modules not being profiled are reported
at the top of output.
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: Sep 2004
gprof(1) gprof(1)
Shared Library Profiling [Toc] [Back]
Support for gprof profiling of shared libraries is available both on
32-bit and 64-bit Itanium-based systems. On PA-RISC systems only 32-
bit shared library profiling is supported.
On Itanium-based systems [Toc] [Back]
The environment variable LD_PROFILE determines what load modules
get profiled. Set LD_PROFILE=ALL to profile all load modules;
that is, report timing and call count information for all
loadable modules, including a.out. Set LD_PROFILE=ldm1:ldm2 to
profile only loadable modules ldm1 and ldm2. ldm1 and ldm2 are
not full pathnames; they are the names recorded in the
executables, which can be displayed using chatr(1). If
LD_PROFILE is not set, gprof behaves as though LD_PROFILE=ALL.
The environment variable LD_PROFILEBUCKET_SIZE controls the size
of profiling counters. The acceptable value for this variable is
16 or 32. Counter size can also be specified at compile time
using the +profilebucketsize option. The runtime value overrides
the compile time value. A warning is issued if the counter size
is set to a value other than 16 or 32; in this case the value
specified at compile time is used. The default value of the
counter is 16, which is used if a valid value is not specified.
See the description of the +profilebucketsize option in cc(1) for
more details.
At program termination the gprof library dumps all profiling
information on a per-module basis in gmon.out, which the gprof
command reads and matches to corresponding functions in the load
modules.
On PA-RISC systems [Toc] [Back]
To profile a shared library, set the environment variable
LD_PROFILE to the path of the shared library to be profiled.
(See HP-UX Linker and Libraries Online User's Guide for details.)
Do not use the -G option to compile programs for shared library
profiling. Do not link the executable gcrt0.o or mcrt0.o. This
turns on profiling of a.out, which is not compatible with
profiling of shared libraries. You can either profile your
executable or a shared library, but not both.
Set LD_PROFILE to the exact string with which you call shl_load.
If the library is implicitly loaded, LD_PROFILE must match the
path encoded in the a.out. You can find this value by running
the ldd command on the executable.
At the termination of the program, a profile file with the name
of the shared library prepended to it is generated by a run-time
library. To get the complete listing, provide the gprof command
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: Sep 2004
gprof(1) gprof(1)
with names of the shared library and the profile file for the
shared library as arguments.
Options [Toc] [Back]
The gprof command recognizes the following options:
-a Suppress printing statically declared functions.
If this option is given, all relevant information
about the static function (such as time samples,
calls to other functions, and calls from other
functions) belongs to the function loaded just
before the static function in the a.out file.
-b Suppress printing a description of each field in
the profile.
-e name Suppress printing the graph profile entry for
routine name and all its descendants (unless they
have other ancestors that are not suppressed).
More than one -e option can be given. Only one
name can be given with each -e option.
-E name Suppress printing the graph profile entry for
routine name (and its descendants) as -e above,
and also exclude the time spent in name (and its
descendants) from the total and percentage time
computations. -E mcount -E mcleanup is the
default.
-f name Print only the graph profile entry of the
specified routine name and its descendants. More
than one -f option can be given. Only one name
can be given with each -f option.
-F name Print only the graph profile entry of the routine
name and its descendants (as -f above) and also
use only the times of the printed routines in
total time and percentage computations. More than
one -F option can be given. Only one name can be
given with each -F option. The -F option
overrides the -E option.
-p Produce just the flat profile output exactly
similar to one given by prof (see prof(1)).
-s Produce a profile file gmon.sum that represents
the sum of the profile information in all
specified profile files. This summary profile
file can be given to subsequent executions of
gprof (probably also with a -s option) to
accumulate profile data across several runs of an
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: Sep 2004
gprof(1) gprof(1)
a.out file. LD_PROFILE should be set to the same
string for all the runs.
-t Produce just the static output in gprof. This is
used for testing purposes. It eliminates all the
timing information from normal gprof output and
reports only the call count part.
-z Display routines that have zero usage (as
indicated by call counts and accumulated time).
The environment variable GPROFDIR controls the name of the file
created by a profiled program. If GPROFDIR is not set, gmon.out is
produced in the current directory when the program terminates. If
GPROFDIR=string, string/pid.progname is produced, where progname is
argv[0] with any path prefix removed, and pid is the program's process
ID. If GPROFDIR is set to a null string, no profiling output is
produced.
EXTERNAL INFLUENCES [Toc] [Back]
Environment Variables
LD_PROFILE determines the modules to be profiled.
LD_PROFILEBUCKET_SIZE controls the size of profiling counters.
GPROFDIR controls the path and name of the file
created by a profiled program.
EXAMPLES [Toc] [Back]
To profile a.out and libtest.so on Itanium-based systems:
$ cat > test.c
void a()
{
printf("I in a\n");
}
$ cc -c +Z -G test.c
$ ld -b -o libtest.so.1 test.o
$ ln -s ./libtest.so.1 libtest.so
$ cat > main.c
extern void a();
main()
{
printf("Hello world\n");
a();
}
$ cc -G main.c -L. -ltest
$ export LD_PROFILE=a.out:libtest.so
$ export LD_PROFILEBUCKET_SIZE=16
Hewlett-Packard Company - 4 - HP-UX 11i Version 2: Sep 2004
gprof(1) gprof(1)
$ ./a.out
hello world
I in a
$ unset LD_PROFILE
$ unset LD_PROFILEBUCKET_SIZE
$ ls gmon.out
gmon.out
$ gprof
To profile libc.sl on PA-RISC systems:
$ cat > test.c
main()
{
printf("hello world\n");
}
$ cc test.c -lc
$ ldd a.out
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
$ export LD_PROFILE=/usr/lib/libc.2
$ ./a.out
hello world
$ unset LD_PROFILE
$ ls libc.2.profile
libc.2.profile
$ gprof /usr/lib/libc.2 libc.2.profile
WARNINGS [Toc] [Back]
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.
Parents that are not profiled have the time of their profiled children
propagated to them, but they appear to be spontaneously invoked in the
call graph listing, and do not have their time propagated further.
Similarly, signal catchers, even though profiled, 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
Hewlett-Packard Company - 5 - HP-UX 11i Version 2: Sep 2004
gprof(1) gprof(1)
the profiling routine, in which case all is lost.
The following limitations exist for gprof shared library profiling on
PA-RISC systems:
+ Local, static, and hidden functions are not profiled.
+ Shared libraries built with -B symbolic are not profiled.
+ Any function calls made from library initializers are not
collected.
DEPENDENCIES [Toc] [Back]
gprof cannot be used with dynamically linked executables (built with
ld -A in pre-HP-UX 10.20 releases).
AUTHOR [Toc] [Back]
gprof was developed by the University of California, Berkeley.
FILES [Toc] [Back]
a.out* Default object file.
gmon.out* Default dynamic call graph and
profile.
gmon.sum* Summarized dynamic call graph and
profile.
/usr/lib/gprof.callg* Call graph description.
/usr/lib/gprof.flat* Flat profile description.
/usr/lib/hpux32/libgprof.so gprof 32-bit shared library on
Itanium-based systems.
/usr/lib/hpux64/libgprof.so gprof 64-bit shared library on
Itanium-based systems.
/usr/lib/libgprof32.sl gprof 32-bit shared library on PARISC
systems.
/usr/lib/pa20_64/libgprof.sl gprof 64-bit shared library on PARISC
systems.
SEE ALSO [Toc] [Back]
aCC(1), cc(1), cc_bundled(1), f90(1), ld(1), prof(1), exit(2),
profil(2), sprofil(2), monitor(3C), smonitor(3C), crt0(3).
gprof: A Call Graph Execution Profiler; Graham, S.L., Kessler, P.B.,
McKusick, M.K.
Proceedings of the SIGPLAN '82 Symposium on Compiler Construction;
SIGPLAN Notices; Vol. 17, No. 6, pp. 120-126, June 1982.
HP-UX Linker and Libraries Online User's Guide (See the ld +help
option).
Hewlett-Packard Company - 6 - HP-UX 11i Version 2: Sep 2004 [ Back ] |
