@smallexample
@c man begin SYNOPSIS
-gprof [ -[abcDhilLsTvwxyz] ] [ -[ACeEfFJnNOpPqQZ][@var{name}] ]
+gprof [ -[abcDhilLrsTvwxyz] ] [ -[ACeEfFJnNOpPqQZ][@var{name}] ]
[ -I @var{dirs} ] [ -d[@var{num}] ] [ -k @var{from/to} ]
- [ -m @var{min-count} ] [ -t @var{table-length} ]
+ [ -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}] ]
@end example
Note: The @samp{-pg} option must be part of your compilation options
-as well as your link options. If it is not, when you run @code{gprof}
-you will get no profile report and an error message like this:
+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
+
+ % the percentage of the total running time of the
+@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
enable @code{gprof} to construct an annotated source code
listing showing how many times each line of code was executed.
+It also worth noting that GCC supports a different profiling method
+which is enabled by the @samp{-fprofile-arcs}, @samp{-ftest-coverage}
+and @samp{-fprofile-values} switches. These switches do not produce
+data which is useful to @code{gprof} however, so they are not
+discussed further here. There is also the
+@samp{-finstrument-functions} switch which will cause GCC to 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
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.
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 --function-ordering
+@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
in a particular order is system dependent and out of the scope of this
manual.
-@item --file-ordering @var{map_file}
+@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
If @var{num} is not specified, enable all debugging.
@xref{Debugging}.
+@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
@section Estimating @code{children} Times
Some of the figures in the call graph are estimates---for example, the
-@code{children} time values and all the the time figures in caller and
+@code{children} time values and all the time figures in caller and
subroutine lines.
There is no direct information about these measurements in the profile
Because @code{gprof} can only report call times and counts by function,
the best way to get finer-grained information on where the program
is spending its time is to re-factor large functions into sequences
-of calls to smaller ones.
+of calls to smaller ones. Beware however that this can introduce
+artifical hot spots since compiling with @samp{-pg} adds a significant
+overhead to function calls. An alternative solution is to use a
+non-intrusive profiler, e.g.@: oprofile.
@item How do I find which lines in my program were executed the most times?
projects / deliverable / binutils-gdb.git / blobdiff