gprof.texi

基于4个mips核的noc设计

            0.00    0.00    3730/13496       ct_init (trees.c:385)
            0.00    0.00    6525/13496       ct_init (trees.c:387)
[6]  0.0    0.00    0.00   13496         init_block (trees.c:408)

@end smallexample


@node Annotated Source,,Line-by-line,Output
@section The Annotated Source Listing

@code{gprof}'s @samp{-A} option triggers an annotated source listing,
which lists the program's source code, each function labeled with the
number of times it was called.  You may also need to specify the
@samp{-I} option, if @code{gprof} can't find the source code files.

Compiling with @samp{gcc @dots{} -g -pg -a} augments your program
with basic-block counting code, in addition to function counting code.
This enables @code{gprof} to determine how many times each line
of code was executed.
For example, consider the following function, taken from gzip,
with line numbers added:

@smallexample
 1 ulg updcrc(s, n)
 2     uch *s;
 3     unsigned n;
 4 @{
 5     register ulg c;
 6
 7     static ulg crc = (ulg)0xffffffffL;
 8
 9     if (s == NULL) @{
10         c = 0xffffffffL;
11     @} else @{
12         c = crc;
13         if (n) do @{
14             c = crc_32_tab[...];
15         @} while (--n);
16     @}
17     crc = c;
18     return c ^ 0xffffffffL;
19 @}

@end smallexample

@code{updcrc} has at least five basic-blocks.
One is the function itself.  The
@code{if} statement on line 9 generates two more basic-blocks, one
for each branch of the @code{if}.  A fourth basic-block results from
the @code{if} on line 13, and the contents of the @code{do} loop form
the fifth basic-block.  The compiler may also generate additional
basic-blocks to handle various special cases.

A program augmented for basic-block counting can be analyzed with
@samp{gprof -l -A}.  I also suggest use of the @samp{-x} option,
which ensures that each line of code is labeled at least once.
Here is @code{updcrc}'s
annotated source listing for a sample @code{gzip} run:

@smallexample
                ulg updcrc(s, n)
                    uch *s;
                    unsigned n;
            2 ->@{
                    register ulg c;
                
                    static ulg crc = (ulg)0xffffffffL;
                
            2 ->    if (s == NULL) @{
            1 ->	c = 0xffffffffL;
            1 ->    @} else @{
            1 ->	c = crc;
            1 ->        if (n) do @{
        26312 ->            c = crc_32_tab[...];
26312,1,26311 ->        @} while (--n);
                    @}
            2 ->    crc = c;
            2 ->    return c ^ 0xffffffffL;
            2 ->@}
@end smallexample

In this example, the function was called twice, passing once through
each branch of the @code{if} statement.  The body of the @code{do}
loop was executed a total of 26312 times.  Note how the @code{while}
statement is annotated.  It began execution 26312 times, once for
each iteration through the loop.  One of those times (the last time)
it exited, while it branched back to the beginning of the loop 26311 times.

@node Inaccuracy
@chapter Inaccuracy of @code{gprof} Output

@menu
* Sampling Error::      Statistical margins of error
* Assumptions::         Estimating children times
@end menu

@node Sampling Error,Assumptions,,Inaccuracy
@section Statistical Sampling Error

The run-time figures that @code{gprof} gives you are based on a sampling
process, so they are subject to statistical inaccuracy.  If a function runs
only a small amount of time, so that on the average the sampling process
ought to catch that function in the act only once, there is a pretty good
chance it will actually find that function zero times, or twice.

By contrast, the number-of-calls and basic-block figures
are derived by counting, not
sampling.  They are completely accurate and will not vary from run to run
if your program is deterministic.

The @dfn{sampling period} that is printed at the beginning of the flat
profile says how often samples are taken.  The rule of thumb is that a
run-time figure is accurate if it is considerably bigger than the sampling
period.

The actual amount of error can be predicted.
For @var{n} samples, the @emph{expected} error
is the square-root of @var{n}.  For example,
if the sampling period is 0.01 seconds and @code{foo}'s run-time is 1 second,
@var{n} is 100 samples (1 second/0.01 seconds), sqrt(@var{n}) is 10 samples, so
the expected error in @code{foo}'s run-time is 0.1 seconds (10*0.01 seconds),
or ten percent of the observed value.
Again, if the sampling period is 0.01 seconds and @code{bar}'s run-time is
100 seconds, @var{n} is 10000 samples, sqrt(@var{n}) is 100 samples, so
the expected error in @code{bar}'s run-time is 1 second,
or one percent of the observed value.
It is likely to
vary this much @emph{on the average} from one profiling run to the next.
(@emph{Sometimes} it will vary more.)

This does not mean that a small run-time figure is devoid of information.
If the program's @emph{total} run-time is large, a small run-time for one
function does tell you that that function used an insignificant fraction of
the whole program's time.  Usually this means it is not worth optimizing.

One way to get more accuracy is to give your program more (but similar)
input data so it will take longer.  Another way is to combine the data from
several runs, using the @samp{-s} option of @code{gprof}.  Here is how:

@enumerate
@item
Run your program once.

@item
Issue the command @samp{mv gmon.out gmon.sum}.

@item
Run your program again, the same as before.

@item
Merge the new data in @file{gmon.out} into @file{gmon.sum} with this command:

@example
gprof -s @var{executable-file} gmon.out gmon.sum
@end example

@item
Repeat the last two steps as often as you wish.

@item
Analyze the cumulative data using this command:

@example
gprof @var{executable-file} gmon.sum > @var{output-file}
@end example
@end enumerate

@node Assumptions,,Sampling Error,Inaccuracy
@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
subroutine lines.

There is no direct information about these measurements in the profile
data itself.  Instead, @code{gprof} estimates them by making an assumption
about your program that might or might not be true.

The assumption made is that the average time spent in each call to any
function @code{foo} is not correlated with who called @code{foo}.  If
@code{foo} used 5 seconds in all, and 2/5 of the calls to @code{foo} came
from @code{a}, then @code{foo} contributes 2 seconds to @code{a}'s
@code{children} time, by assumption.

This assumption is usually true enough, but for some programs it is far
from true.  Suppose that @code{foo} returns very quickly when its argument
is zero; suppose that @code{a} always passes zero as an argument, while
other callers of @code{foo} pass other arguments.  In this program, all the
time spent in @code{foo} is in the calls from callers other than @code{a}.
But @code{gprof} has no way of knowing this; it will blindly and
incorrectly charge 2 seconds of time in @code{foo} to the children of
@code{a}.

@c FIXME - has this been fixed?
We hope some day to put more complete data into @file{gmon.out}, so that
this assumption is no longer needed, if we can figure out how.  For the
nonce, the estimated figures are usually more useful than misleading.

@node How do I?
@chapter Answers to Common Questions

@table @asis
@item How do I find which lines in my program were executed the most times?

Compile your program with basic-block counting enabled, run it, then
use the following pipeline:

@example
gprof -l -C @var{objfile} | sort -k 3 -n -r
@end example

This listing will show you the lines in your code executed most often,
but not necessarily those that consumed the most time.

@item How do I find which lines in my program called a particular function?

Use @samp{gprof -l} and lookup the function in the call graph.
The callers will be broken down by function and line number.

@item How do I analyze a program that runs for less than a second?

Try using a shell script like this one:

@example
for i in `seq 1 100`; do
  fastprog
  mv gmon.out gmon.out.$i
done

gprof -s fastprog gmon.out.*

gprof fastprog gmon.sum
@end example

If your program is completely deterministic, all the call counts
will be simple multiples of 100 (i.e. a function called once in
each run will appear with a call count of 100).

@end table

@node Incompatibilities
@chapter Incompatibilities with Unix @code{gprof}

@sc{gnu} @code{gprof} and Berkeley Unix @code{gprof} use the same data
file @file{gmon.out}, and provide essentially the same information.  But
there are a few differences.

@itemize @bullet
@item
@sc{gnu} @code{gprof} uses a new, generalized file format with support
for basic-block execution counts and non-realtime histograms.  A magic
cookie and version number allows @code{gprof} to easily identify
new style files.  Old BSD-style files can still be read.
@xref{File Format}.

@item
For a recursive function, Unix @code{gprof} lists the function as a
parent and as a child, with a @code{calls} field that lists the number
of recursive calls.  @sc{gnu} @code{gprof} omits these lines and puts
the number of recursive calls in the primary line.

@item
When a function is suppressed from the call graph with @samp{-e}, @sc{gnu}
@code{gprof} still lists it as a subroutine of functions that call it.

@item
@sc{gnu} @code{gprof} accepts the @samp{-k} with its argument
in the form @samp{from/to}, instead of @samp{from to}.

@item
In the annotated source listing,
if there are multiple basic blocks on the same line,
@sc{gnu} @code{gprof} prints all of their counts, separated by commas.

@ignore - it does this now
@item
The function names printed in @sc{gnu} @code{gprof} output do not include
the leading underscores that are added internally to the front of all
C identifiers on many operating systems.
@end ignore

@item
The blurbs, field widths, and output formats are different.  @sc{gnu}
@code{gprof} prints blurbs after the tables, so that you can see the
tables without skipping the blurbs.
@end itemize

@node Details
@chapter Details of Profiling

@menu
* Implementation::      How a program collects profiling information
* File Format::         Format of @samp{gmon.out} files
* Internals::           @code{gprof}'s internal operation
* Debugging::           Using @code{gprof}'s @samp{-d} option
@end menu

@node Implementation,File Format,,Details
@section Implementation of Profiling

Profiling works by changing how every function in your program is compiled
so that when it is called, it will stash away some information about where
it was called from.  From this, the profiler can figure out what function
called it, and can count how many times it was called.  This change is made
by the compiler when your program is compiled with the @samp{-pg} option,
which causes every function to call @code{mcount}
(or @code{_mcount}, or @code{__mcount}, depending on the OS and compiler)
as one of its first operations.

The @code{mcount} routine, included in the profiling library,
is responsible for recording in an in-memory call graph table
both its parent routine (the child) and its parent's parent.  This is
typically done by examining the stack frame to find both
the address of the child, and the return address in the original parent.
Since this is a very machine-dependent operation, @code{mcount}
itself is typically a short assembly-language stub routine
that extracts the required
information, and then calls @code{__mcount_internal}
(a normal C function) with two arguments - @code{frompc} and @code{selfpc}.
@code{__mcount_internal} is responsible for maintaining
the in-memory call graph, which records @code{frompc}, @code{selfpc},
and the number of times each of these call arcs was traversed.

GCC Version 2 provides a magical function (@code{__builtin_return_address}),
which allows a generic @code{mcount} function to extract the
required information from the stack frame.  However, on some
architectures, most notably the SPARC, using this builtin