1 \input texinfo @c -*-texinfo-*-
2 @setfilename gprof.info
3 @c Copyright 1988, 1992, 1993, 1998, 1999, 2000, 2001, 2002, 2003,
5 @c Free Software Foundation, Inc.
14 @c This is a dir.info fragment to support semi-automated addition of
15 @c manuals to an info tree. zoo@cygnus.com is developing this facility.
18 * gprof: (gprof). Profiling your program's execution
24 This file documents the gprof profiler of the GNU system.
26 @c man begin COPYRIGHT
27 Copyright @copyright{} 1988, 92, 97, 98, 99, 2000, 2001, 2003, 2007 Free Software Foundation, Inc.
29 Permission is granted to copy, distribute and/or modify this document
30 under the terms of the GNU Free Documentation License, Version 1.1
31 or any later version published by the Free Software Foundation;
32 with no Invariant Sections, with no Front-Cover Texts, and with no
33 Back-Cover Texts. A copy of the license is included in the
34 section entitled ``GNU Free Documentation License''.
45 @subtitle The @sc{gnu} Profiler
46 @ifset VERSION_PACKAGE
47 @subtitle @value{VERSION_PACKAGE}
49 @subtitle Version @value{VERSION}
50 @author Jay Fenlason and Richard Stallman
54 This manual describes the @sc{gnu} profiler, @code{gprof}, and how you
55 can use it to determine which parts of a program are taking most of the
56 execution time. We assume that you know how to write, compile, and
57 execute programs. @sc{gnu} @code{gprof} was written by Jay Fenlason.
58 Eric S. Raymond made some minor corrections and additions in 2003.
60 @vskip 0pt plus 1filll
61 Copyright @copyright{} 1988, 92, 97, 98, 99, 2000, 2003 Free Software Foundation, Inc.
63 Permission is granted to copy, distribute and/or modify this document
64 under the terms of the GNU Free Documentation License, Version 1.1
65 or any later version published by the Free Software Foundation;
66 with no Invariant Sections, with no Front-Cover Texts, and with no
67 Back-Cover Texts. A copy of the license is included in the
68 section entitled ``GNU Free Documentation License''.
75 @top Profiling a Program: Where Does It Spend Its Time?
77 This manual describes the @sc{gnu} profiler, @code{gprof}, and how you
78 can use it to determine which parts of a program are taking most of the
79 execution time. We assume that you know how to write, compile, and
80 execute programs. @sc{gnu} @code{gprof} was written by Jay Fenlason.
82 This manual is for @code{gprof}
83 @ifset VERSION_PACKAGE
84 @value{VERSION_PACKAGE}
86 version @value{VERSION}.
88 This document is distributed under the terms of the GNU Free
89 Documentation License. A copy of the license is included in the
90 section entitled ``GNU Free Documentation License''.
93 * Introduction:: What profiling means, and why it is useful.
95 * Compiling:: How to compile your program for profiling.
96 * Executing:: Executing your program to generate profile data
97 * Invoking:: How to run @code{gprof}, and its options
99 * Output:: Interpreting @code{gprof}'s output
101 * Inaccuracy:: Potential problems you should be aware of
102 * How do I?:: Answers to common questions
103 * Incompatibilities:: (between @sc{gnu} @code{gprof} and Unix @code{gprof}.)
104 * Details:: Details of how profiling is done
105 * GNU Free Documentation License:: GNU Free Documentation License
110 @chapter Introduction to Profiling
113 @c man title gprof display call graph profile data
116 @c man begin SYNOPSIS
117 gprof [ -[abcDhilLrsTvwxyz] ] [ -[ACeEfFJnNOpPqQZ][@var{name}] ]
118 [ -I @var{dirs} ] [ -d[@var{num}] ] [ -k @var{from/to} ]
119 [ -m @var{min-count} ] [ -R @var{map_file} ] [ -t @var{table-length} ]
120 [ --[no-]annotated-source[=@var{name}] ]
121 [ --[no-]exec-counts[=@var{name}] ]
122 [ --[no-]flat-profile[=@var{name}] ] [ --[no-]graph[=@var{name}] ]
123 [ --[no-]time=@var{name}] [ --all-lines ] [ --brief ]
124 [ --debug[=@var{level}] ] [ --function-ordering ]
125 [ --file-ordering @var{map_file} ] [ --directory-path=@var{dirs} ]
126 [ --display-unused-functions ] [ --file-format=@var{name} ]
127 [ --file-info ] [ --help ] [ --line ] [ --min-count=@var{n} ]
128 [ --no-static ] [ --print-path ] [ --separate-files ]
129 [ --static-call-graph ] [ --sum ] [ --table-length=@var{len} ]
130 [ --traditional ] [ --version ] [ --width=@var{n} ]
131 [ --ignore-non-functions ] [ --demangle[=@var{STYLE}] ]
132 [ --no-demangle ] [ @var{image-file} ] [ @var{profile-file} @dots{} ]
136 @c man begin DESCRIPTION
137 @code{gprof} produces an execution profile of C, Pascal, or Fortran77
138 programs. The effect of called routines is incorporated in the profile
139 of each caller. The profile data is taken from the call graph profile file
140 (@file{gmon.out} default) which is created by programs
141 that are compiled with the @samp{-pg} option of
142 @code{cc}, @code{pc}, and @code{f77}.
143 The @samp{-pg} option also links in versions of the library routines
144 that are compiled for profiling. @code{Gprof} reads the given object
145 file (the default is @code{a.out}) and establishes the relation between
146 its symbol table and the call graph profile from @file{gmon.out}.
147 If more than one profile file is specified, the @code{gprof}
148 output shows the sum of the profile information in the given profile files.
150 @code{Gprof} calculates the amount of time spent in each routine.
151 Next, these times are propagated along the edges of the call graph.
152 Cycles are discovered, and calls into a cycle are made to share the time
158 The granularity of the sampling is shown, but remains
160 We assume that the time for each execution of a function
161 can be expressed by the total time for the function divided
162 by the number of times the function is called.
163 Thus the time propagated along the call graph arcs to the function's
164 parents is directly proportional to the number of times that
167 Parents that are not themselves profiled will have the time of
168 their profiled children propagated to them, but they will appear
169 to be spontaneously invoked in the call graph listing, and will
170 not have their time propagated further.
171 Similarly, signal catchers, even though profiled, will appear
172 to be spontaneous (although for more obscure reasons).
173 Any profiled children of signal catchers should have their times
174 propagated properly, unless the signal catcher was invoked during
175 the execution of the profiling routine, in which case all is lost.
177 The profiled program must call @code{exit}(2)
178 or return normally for the profiling information to be saved
179 in the @file{gmon.out} file.
185 the namelist and text space.
186 @item @file{gmon.out}
187 dynamic call graph and profile.
188 @item @file{gmon.sum}
189 summarized dynamic call graph and profile.
194 monitor(3), profil(2), cc(1), prof(1), and the Info entry for @file{gprof}.
196 ``An Execution Profiler for Modular Programs'',
197 by S. Graham, P. Kessler, M. McKusick;
198 Software - Practice and Experience,
199 Vol. 13, pp. 671-685, 1983.
201 ``gprof: A Call Graph Execution Profiler'',
202 by S. Graham, P. Kessler, M. McKusick;
203 Proceedings of the SIGPLAN '82 Symposium on Compiler Construction,
204 SIGPLAN Notices, Vol. 17, No 6, pp. 120-126, June 1982.
208 Profiling allows you to learn where your program spent its time and which
209 functions called which other functions while it was executing. This
210 information can show you which pieces of your program are slower than you
211 expected, and might be candidates for rewriting to make your program
212 execute faster. It can also tell you which functions are being called more
213 or less often than you expected. This may help you spot bugs that had
214 otherwise been unnoticed.
216 Since the profiler uses information collected during the actual execution
217 of your program, it can be used on programs that are too large or too
218 complex to analyze by reading the source. However, how your program is run
219 will affect the information that shows up in the profile data. If you
220 don't use some feature of your program while it is being profiled, no
221 profile information will be generated for that feature.
223 Profiling has several steps:
227 You must compile and link your program with profiling enabled.
228 @xref{Compiling, ,Compiling a Program for Profiling}.
231 You must execute your program to generate a profile data file.
232 @xref{Executing, ,Executing the Program}.
235 You must run @code{gprof} to analyze the profile data.
236 @xref{Invoking, ,@code{gprof} Command Summary}.
239 The next three chapters explain these steps in greater detail.
241 @c man begin DESCRIPTION
243 Several forms of output are available from the analysis.
245 The @dfn{flat profile} shows how much time your program spent in each function,
246 and how many times that function was called. If you simply want to know
247 which functions burn most of the cycles, it is stated concisely here.
248 @xref{Flat Profile, ,The Flat Profile}.
250 The @dfn{call graph} shows, for each function, which functions called it, which
251 other functions it called, and how many times. There is also an estimate
252 of how much time was spent in the subroutines of each function. This can
253 suggest places where you might try to eliminate function calls that use a
254 lot of time. @xref{Call Graph, ,The Call Graph}.
256 The @dfn{annotated source} listing is a copy of the program's
257 source code, labeled with the number of times each line of the
258 program was executed. @xref{Annotated Source, ,The Annotated Source
262 To better understand how profiling works, you may wish to read
263 a description of its implementation.
264 @xref{Implementation, ,Implementation of Profiling}.
267 @chapter Compiling a Program for Profiling
269 The first step in generating profile information for your program is
270 to compile and link it with profiling enabled.
272 To compile a source file for profiling, specify the @samp{-pg} option when
273 you run the compiler. (This is in addition to the options you normally
276 To link the program for profiling, if you use a compiler such as @code{cc}
277 to do the linking, simply specify @samp{-pg} in addition to your usual
278 options. The same option, @samp{-pg}, alters either compilation or linking
279 to do what is necessary for profiling. Here are examples:
282 cc -g -c myprog.c utils.c -pg
283 cc -o myprog myprog.o utils.o -pg
286 The @samp{-pg} option also works with a command that both compiles and links:
289 cc -o myprog myprog.c utils.c -g -pg
292 Note: The @samp{-pg} option must be part of your compilation options
293 as well as your link options. If it is not then no call-graph data
294 will be gathered and when you run @code{gprof} you will get an error
298 gprof: gmon.out file is missing call-graph data
301 If you add the @samp{-Q} switch to suppress the printing of the call
302 graph data you will still be able to see the time samples:
307 Each sample counts as 0.01 seconds.
308 % cumulative self self total
309 time seconds seconds calls Ts/call Ts/call name
310 44.12 0.07 0.07 zazLoop
312 20.59 0.17 0.04 bazMillion
315 If you run the linker @code{ld} directly instead of through a compiler
316 such as @code{cc}, you may have to specify a profiling startup file
317 @file{gcrt0.o} as the first input file instead of the usual startup
318 file @file{crt0.o}. In addition, you would probably want to
319 specify the profiling C library, @file{libc_p.a}, by writing
320 @samp{-lc_p} instead of the usual @samp{-lc}. This is not absolutely
321 necessary, but doing this gives you number-of-calls information for
322 standard library functions such as @code{read} and @code{open}. For
326 ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p
329 If you compile only some of the modules of the program with @samp{-pg}, you
330 can still profile the program, but you won't get complete information about
331 the modules that were compiled without @samp{-pg}. The only information
332 you get for the functions in those modules is the total time spent in them;
333 there is no record of how many times they were called, or from where. This
334 will not affect the flat profile (except that the @code{calls} field for
335 the functions will be blank), but will greatly reduce the usefulness of the
338 If you wish to perform line-by-line profiling,
339 you will also need to specify the @samp{-g} option,
340 instructing the compiler to insert debugging symbols into the program
341 that match program addresses to source code lines.
342 @xref{Line-by-line, ,Line-by-line Profiling}.
344 In addition to the @samp{-pg} and @samp{-g} options, older versions of
345 GCC required you to specify the @samp{-a} option when compiling in
346 order to instrument it to perform basic-block counting. Newer
347 versions do not require this option and will not accept it;
348 basic-block counting is always enabled when @samp{-pg} is on.
350 When basic-block counting is enabled, as the program runs
351 it will count how many times it executed each branch of each @samp{if}
352 statement, each iteration of each @samp{do} loop, etc. This will
353 enable @code{gprof} to construct an annotated source code
354 listing showing how many times each line of code was executed.
356 It also worth noting that GCC supports a different profiling method
357 which is enabled by the @samp{-fprofile-arcs}, @samp{-ftest-coverage}
358 and @samp{-fprofile-values} switches. These switches do not produce
359 data which is useful to @code{gprof} however, so they are not
360 discussed further here. There is also the
361 @samp{-finstrument-functions} switch which will cause GCC to insert
362 calls to special user supplied instrumentation routines at the entry
363 and exit of every function in their program. This can be used to
364 implement an alternative profiling scheme.
367 @chapter Executing the Program
369 Once the program is compiled for profiling, you must run it in order to
370 generate the information that @code{gprof} needs. Simply run the program
371 as usual, using the normal arguments, file names, etc. The program should
372 run normally, producing the same output as usual. It will, however, run
373 somewhat slower than normal because of the time spent collecting and
374 writing the profile data.
376 The way you run the program---the arguments and input that you give
377 it---may have a dramatic effect on what the profile information shows. The
378 profile data will describe the parts of the program that were activated for
379 the particular input you use. For example, if the first command you give
380 to your program is to quit, the profile data will show the time used in
381 initialization and in cleanup, but not much else.
383 Your program will write the profile data into a file called @file{gmon.out}
384 just before exiting. If there is already a file called @file{gmon.out},
385 its contents are overwritten. There is currently no way to tell the
386 program to write the profile data under a different name, but you can rename
387 the file afterwards if you are concerned that it may be overwritten.
389 In order to write the @file{gmon.out} file properly, your program must exit
390 normally: by returning from @code{main} or by calling @code{exit}. Calling
391 the low-level function @code{_exit} does not write the profile data, and
392 neither does abnormal termination due to an unhandled signal.
394 The @file{gmon.out} file is written in the program's @emph{current working
395 directory} at the time it exits. This means that if your program calls
396 @code{chdir}, the @file{gmon.out} file will be left in the last directory
397 your program @code{chdir}'d to. If you don't have permission to write in
398 this directory, the file is not written, and you will get an error message.
400 Older versions of the @sc{gnu} profiling library may also write a file
401 called @file{bb.out}. This file, if present, contains an human-readable
402 listing of the basic-block execution counts. Unfortunately, the
403 appearance of a human-readable @file{bb.out} means the basic-block
404 counts didn't get written into @file{gmon.out}.
405 The Perl script @code{bbconv.pl}, included with the @code{gprof}
406 source distribution, will convert a @file{bb.out} file into
407 a format readable by @code{gprof}. Invoke it like this:
410 bbconv.pl < bb.out > @var{bh-data}
413 This translates the information in @file{bb.out} into a form that
414 @code{gprof} can understand. But you still need to tell @code{gprof}
415 about the existence of this translated information. To do that, include
416 @var{bb-data} on the @code{gprof} command line, @emph{along with
417 @file{gmon.out}}, like this:
420 gprof @var{options} @var{executable-file} gmon.out @var{bb-data} [@var{yet-more-profile-data-files}@dots{}] [> @var{outfile}]
424 @chapter @code{gprof} Command Summary
426 After you have a profile data file @file{gmon.out}, you can run @code{gprof}
427 to interpret the information in it. The @code{gprof} program prints a
428 flat profile and a call graph on standard output. Typically you would
429 redirect the output of @code{gprof} into a file with @samp{>}.
431 You run @code{gprof} like this:
434 gprof @var{options} [@var{executable-file} [@var{profile-data-files}@dots{}]] [> @var{outfile}]
438 Here square-brackets indicate optional arguments.
440 If you omit the executable file name, the file @file{a.out} is used. If
441 you give no profile data file name, the file @file{gmon.out} is used. If
442 any file is not in the proper format, or if the profile data file does not
443 appear to belong to the executable file, an error message is printed.
445 You can give more than one profile data file by entering all their names
446 after the executable file name; then the statistics in all the data files
449 The order of these options does not matter.
452 * Output Options:: Controlling @code{gprof}'s output style
453 * Analysis Options:: Controlling how @code{gprof} analyzes its data
454 * Miscellaneous Options::
455 * Deprecated Options:: Options you no longer need to use, but which
456 have been retained for compatibility
457 * Symspecs:: Specifying functions to include or exclude
461 @section Output Options
464 These options specify which of several output formats
465 @code{gprof} should produce.
467 Many of these options take an optional @dfn{symspec} to specify
468 functions to be included or excluded. These options can be
469 specified multiple times, with different symspecs, to include
470 or exclude sets of symbols. @xref{Symspecs, ,Symspecs}.
472 Specifying any of these options overrides the default (@samp{-p -q}),
473 which prints a flat profile and call graph analysis
478 @item -A[@var{symspec}]
479 @itemx --annotated-source[=@var{symspec}]
480 The @samp{-A} option causes @code{gprof} to print annotated source code.
481 If @var{symspec} is specified, print output only for matching symbols.
482 @xref{Annotated Source, ,The Annotated Source Listing}.
486 If the @samp{-b} option is given, @code{gprof} doesn't print the
487 verbose blurbs that try to explain the meaning of all of the fields in
488 the tables. This is useful if you intend to print out the output, or
489 are tired of seeing the blurbs.
491 @item -C[@var{symspec}]
492 @itemx --exec-counts[=@var{symspec}]
493 The @samp{-C} option causes @code{gprof} to
494 print a tally of functions and the number of times each was called.
495 If @var{symspec} is specified, print tally only for matching symbols.
497 If the profile data file contains basic-block count records, specifying
498 the @samp{-l} option, along with @samp{-C}, will cause basic-block
499 execution counts to be tallied and displayed.
503 The @samp{-i} option causes @code{gprof} to display summary information
504 about the profile data file(s) and then exit. The number of histogram,
505 call graph, and basic-block count records is displayed.
508 @itemx --directory-path=@var{dirs}
509 The @samp{-I} option specifies a list of search directories in
510 which to find source files. Environment variable @var{GPROF_PATH}
511 can also be used to convey this information.
512 Used mostly for annotated source output.
514 @item -J[@var{symspec}]
515 @itemx --no-annotated-source[=@var{symspec}]
516 The @samp{-J} option causes @code{gprof} not to
517 print annotated source code.
518 If @var{symspec} is specified, @code{gprof} prints annotated source,
519 but excludes matching symbols.
523 Normally, source filenames are printed with the path
524 component suppressed. The @samp{-L} option causes @code{gprof}
525 to print the full pathname of
526 source filenames, which is determined
527 from symbolic debugging information in the image file
528 and is relative to the directory in which the compiler
531 @item -p[@var{symspec}]
532 @itemx --flat-profile[=@var{symspec}]
533 The @samp{-p} option causes @code{gprof} to print a flat profile.
534 If @var{symspec} is specified, print flat profile only for matching symbols.
535 @xref{Flat Profile, ,The Flat Profile}.
537 @item -P[@var{symspec}]
538 @itemx --no-flat-profile[=@var{symspec}]
539 The @samp{-P} option causes @code{gprof} to suppress printing a flat profile.
540 If @var{symspec} is specified, @code{gprof} prints a flat profile,
541 but excludes matching symbols.
543 @item -q[@var{symspec}]
544 @itemx --graph[=@var{symspec}]
545 The @samp{-q} option causes @code{gprof} to print the call graph analysis.
546 If @var{symspec} is specified, print call graph only for matching symbols
548 @xref{Call Graph, ,The Call Graph}.
550 @item -Q[@var{symspec}]
551 @itemx --no-graph[=@var{symspec}]
552 The @samp{-Q} option causes @code{gprof} to suppress printing the
554 If @var{symspec} is specified, @code{gprof} prints a call graph,
555 but excludes matching symbols.
558 @itemx --table-length=@var{num}
559 The @samp{-t} option causes the @var{num} most active source lines in
560 each source file to be listed when source annotation is enabled. The
564 @itemx --separate-files
565 This option affects annotated source output only.
566 Normally, @code{gprof} prints annotated source files
567 to standard-output. If this option is specified,
568 annotated source for a file named @file{path/@var{filename}}
569 is generated in the file @file{@var{filename}-ann}. If the underlying
570 file system would truncate @file{@var{filename}-ann} so that it
571 overwrites the original @file{@var{filename}}, @code{gprof} generates
572 annotated source in the file @file{@var{filename}.ann} instead (if the
573 original file name has an extension, that extension is @emph{replaced}
576 @item -Z[@var{symspec}]
577 @itemx --no-exec-counts[=@var{symspec}]
578 The @samp{-Z} option causes @code{gprof} not to
579 print a tally of functions and the number of times each was called.
580 If @var{symspec} is specified, print tally, but exclude matching symbols.
583 @itemx --function-ordering
584 The @samp{--function-ordering} option causes @code{gprof} to print a
585 suggested function ordering for the program based on profiling data.
586 This option suggests an ordering which may improve paging, tlb and
587 cache behavior for the program on systems which support arbitrary
588 ordering of functions in an executable.
590 The exact details of how to force the linker to place functions
591 in a particular order is system dependent and out of the scope of this
594 @item -R @var{map_file}
595 @itemx --file-ordering @var{map_file}
596 The @samp{--file-ordering} option causes @code{gprof} to print a
597 suggested .o link line ordering for the program based on profiling data.
598 This option suggests an ordering which may improve paging, tlb and
599 cache behavior for the program on systems which do not support arbitrary
600 ordering of functions in an executable.
602 Use of the @samp{-a} argument is highly recommended with this option.
604 The @var{map_file} argument is a pathname to a file which provides
605 function name to object file mappings. The format of the file is similar to
606 the output of the program @code{nm}.
610 c-parse.o:00000000 T yyparse
611 c-parse.o:00000004 C yyerrflag
612 c-lang.o:00000000 T maybe_objc_method_name
613 c-lang.o:00000000 T print_lang_statistics
614 c-lang.o:00000000 T recognize_objc_keyword
615 c-decl.o:00000000 T print_lang_identifier
616 c-decl.o:00000000 T print_lang_type
622 To create a @var{map_file} with @sc{gnu} @code{nm}, type a command like
623 @kbd{nm --extern-only --defined-only -v --print-file-name program-name}.
627 The @samp{-T} option causes @code{gprof} to print its output in
628 ``traditional'' BSD style.
631 @itemx --width=@var{width}
632 Sets width of output lines to @var{width}.
633 Currently only used when printing the function index at the bottom
638 This option affects annotated source output only.
639 By default, only the lines at the beginning of a basic-block
640 are annotated. If this option is specified, every line in
641 a basic-block is annotated by repeating the annotation for the
642 first line. This behavior is similar to @code{tcov}'s @samp{-a}.
644 @item --demangle[=@var{style}]
646 These options control whether C++ symbol names should be demangled when
647 printing output. The default is to demangle symbols. The
648 @code{--no-demangle} option may be used to turn off demangling. Different
649 compilers have different mangling styles. The optional demangling style
650 argument can be used to choose an appropriate demangling style for your
654 @node Analysis Options
655 @section Analysis Options
661 The @samp{-a} option causes @code{gprof} to suppress the printing of
662 statically declared (private) functions. (These are functions whose
663 names are not listed as global, and which are not visible outside the
664 file/function/block where they were defined.) Time spent in these
665 functions, calls to/from them, etc., will all be attributed to the
666 function that was loaded directly before it in the executable file.
667 @c This is compatible with Unix @code{gprof}, but a bad idea.
668 This option affects both the flat profile and the call graph.
671 @itemx --static-call-graph
672 The @samp{-c} option causes the call graph of the program to be
673 augmented by a heuristic which examines the text space of the object
674 file and identifies function calls in the binary machine code.
675 Since normal call graph records are only generated when functions are
676 entered, this option identifies children that could have been called,
677 but never were. Calls to functions that were not compiled with
678 profiling enabled are also identified, but only if symbol table
679 entries are present for them.
680 Calls to dynamic library routines are typically @emph{not} found
682 Parents or children identified via this heuristic
683 are indicated in the call graph with call counts of @samp{0}.
686 @itemx --ignore-non-functions
687 The @samp{-D} option causes @code{gprof} to ignore symbols which
688 are not known to be functions. This option will give more accurate
689 profile data on systems where it is supported (Solaris and HPUX for
692 @item -k @var{from}/@var{to}
693 The @samp{-k} option allows you to delete from the call graph any arcs from
694 symbols matching symspec @var{from} to those matching symspec @var{to}.
698 The @samp{-l} option enables line-by-line profiling, which causes
699 histogram hits to be charged to individual source code lines,
700 instead of functions.
701 If the program was compiled with basic-block counting enabled,
702 this option will also identify how many times each line of
704 While line-by-line profiling can help isolate where in a large function
705 a program is spending its time, it also significantly increases
706 the running time of @code{gprof}, and magnifies statistical
708 @xref{Sampling Error, ,Statistical Sampling Error}.
711 @itemx --min-count=@var{num}
712 This option affects execution count output only.
713 Symbols that are executed less than @var{num} times are suppressed.
715 @item -n@var{symspec}
716 @itemx --time=@var{symspec}
717 The @samp{-n} option causes @code{gprof}, in its call graph analysis,
718 to only propagate times for symbols matching @var{symspec}.
720 @item -N@var{symspec}
721 @itemx --no-time=@var{symspec}
722 The @samp{-n} option causes @code{gprof}, in its call graph analysis,
723 not to propagate times for symbols matching @var{symspec}.
726 @itemx --display-unused-functions
727 If you give the @samp{-z} option, @code{gprof} will mention all
728 functions in the flat profile, even those that were never called, and
729 that had no time spent in them. This is useful in conjunction with the
730 @samp{-c} option for discovering which routines were never called.
734 @node Miscellaneous Options
735 @section Miscellaneous Options
740 @itemx --debug[=@var{num}]
741 The @samp{-d @var{num}} option specifies debugging options.
742 If @var{num} is not specified, enable all debugging.
743 @xref{Debugging, ,Debugging @code{gprof}}.
747 The @samp{-h} option prints command line usage.
750 @itemx --file-format=@var{name}
751 Selects the format of the profile data files. Recognized formats are
752 @samp{auto} (the default), @samp{bsd}, @samp{4.4bsd}, @samp{magic}, and
753 @samp{prof} (not yet supported).
757 The @samp{-s} option causes @code{gprof} to summarize the information
758 in the profile data files it read in, and write out a profile data
759 file called @file{gmon.sum}, which contains all the information from
760 the profile data files that @code{gprof} read in. The file @file{gmon.sum}
761 may be one of the specified input files; the effect of this is to
762 merge the data in the other input files into @file{gmon.sum}.
764 Eventually you can run @code{gprof} again without @samp{-s} to analyze the
765 cumulative data in the file @file{gmon.sum}.
769 The @samp{-v} flag causes @code{gprof} to print the current version
770 number, and then exit.
774 @node Deprecated Options
775 @section Deprecated Options
779 These options have been replaced with newer versions that use symspecs.
781 @item -e @var{function_name}
782 The @samp{-e @var{function}} option tells @code{gprof} to not print
783 information about the function @var{function_name} (and its
784 children@dots{}) in the call graph. The function will still be listed
785 as a child of any functions that call it, but its index number will be
786 shown as @samp{[not printed]}. More than one @samp{-e} option may be
787 given; only one @var{function_name} may be indicated with each @samp{-e}
790 @item -E @var{function_name}
791 The @code{-E @var{function}} option works like the @code{-e} option, but
792 time spent in the function (and children who were not called from
793 anywhere else), will not be used to compute the percentages-of-time for
794 the call graph. More than one @samp{-E} option may be given; only one
795 @var{function_name} may be indicated with each @samp{-E} option.
797 @item -f @var{function_name}
798 The @samp{-f @var{function}} option causes @code{gprof} to limit the
799 call graph to the function @var{function_name} and its children (and
800 their children@dots{}). More than one @samp{-f} option may be given;
801 only one @var{function_name} may be indicated with each @samp{-f}
804 @item -F @var{function_name}
805 The @samp{-F @var{function}} option works like the @code{-f} option, but
806 only time spent in the function and its children (and their
807 children@dots{}) will be used to determine total-time and
808 percentages-of-time for the call graph. More than one @samp{-F} option
809 may be given; only one @var{function_name} may be indicated with each
810 @samp{-F} option. The @samp{-F} option overrides the @samp{-E} option.
816 Note that only one function can be specified with each @code{-e},
817 @code{-E}, @code{-f} or @code{-F} option. To specify more than one
818 function, use multiple options. For example, this command:
821 gprof -e boring -f foo -f bar myprogram > gprof.output
825 lists in the call graph all functions that were reached from either
826 @code{foo} or @code{bar} and were not reachable from @code{boring}.
831 Many of the output options allow functions to be included or excluded
832 using @dfn{symspecs} (symbol specifications), which observe the
836 filename_containing_a_dot
837 | funcname_not_containing_a_dot
839 | ( [ any_filename ] `:' ( any_funcname | linenumber ) )
842 Here are some sample symspecs:
846 Selects everything in file @file{main.c}---the
847 dot in the string tells @code{gprof} to interpret
848 the string as a filename, rather than as
849 a function name. To select a file whose
850 name does not contain a dot, a trailing colon
851 should be specified. For example, @samp{odd:} is
852 interpreted as the file named @file{odd}.
855 Selects all functions named @samp{main}.
857 Note that there may be multiple instances of the same function name
858 because some of the definitions may be local (i.e., static). Unless a
859 function name is unique in a program, you must use the colon notation
860 explained below to specify a function from a specific source file.
862 Sometimes, function names contain dots. In such cases, it is necessary
863 to add a leading colon to the name. For example, @samp{:.mul} selects
864 function @samp{.mul}.
866 In some object file formats, symbols have a leading underscore.
867 @code{gprof} will normally not print these underscores. When you name a
868 symbol in a symspec, you should type it exactly as @code{gprof} prints
869 it in its output. For example, if the compiler produces a symbol
870 @samp{_main} from your @code{main} function, @code{gprof} still prints
871 it as @samp{main} in its output, so you should use @samp{main} in
875 Selects function @samp{main} in file @file{main.c}.
878 Selects line 134 in file @file{main.c}.
882 @chapter Interpreting @code{gprof}'s Output
884 @code{gprof} can produce several different output styles, the
885 most important of which are described below. The simplest output
886 styles (file information, execution count, and function and file ordering)
887 are not described here, but are documented with the respective options
889 @xref{Output Options, ,Output Options}.
892 * Flat Profile:: The flat profile shows how much time was spent
893 executing directly in each function.
894 * Call Graph:: The call graph shows which functions called which
895 others, and how much time each function used
896 when its subroutine calls are included.
897 * Line-by-line:: @code{gprof} can analyze individual source code lines
898 * Annotated Source:: The annotated source listing displays source code
899 labeled with execution counts
904 @section The Flat Profile
907 The @dfn{flat profile} shows the total amount of time your program
908 spent executing each function. Unless the @samp{-z} option is given,
909 functions with no apparent time spent in them, and no apparent calls
910 to them, are not mentioned. Note that if a function was not compiled
911 for profiling, and didn't run long enough to show up on the program
912 counter histogram, it will be indistinguishable from a function that
915 This is part of a flat profile for a small program:
921 Each sample counts as 0.01 seconds.
922 % cumulative self self total
923 time seconds seconds calls ms/call ms/call name
924 33.34 0.02 0.02 7208 0.00 0.00 open
925 16.67 0.03 0.01 244 0.04 0.12 offtime
926 16.67 0.04 0.01 8 1.25 1.25 memccpy
927 16.67 0.05 0.01 7 1.43 1.43 write
928 16.67 0.06 0.01 mcount
929 0.00 0.06 0.00 236 0.00 0.00 tzset
930 0.00 0.06 0.00 192 0.00 0.00 tolower
931 0.00 0.06 0.00 47 0.00 0.00 strlen
932 0.00 0.06 0.00 45 0.00 0.00 strchr
933 0.00 0.06 0.00 1 0.00 50.00 main
934 0.00 0.06 0.00 1 0.00 0.00 memcpy
935 0.00 0.06 0.00 1 0.00 10.11 print
936 0.00 0.06 0.00 1 0.00 0.00 profil
937 0.00 0.06 0.00 1 0.00 50.00 report
943 The functions are sorted first by decreasing run-time spent in them,
944 then by decreasing number of calls, then alphabetically by name. The
945 functions @samp{mcount} and @samp{profil} are part of the profiling
946 apparatus and appear in every flat profile; their time gives a measure of
947 the amount of overhead due to profiling.
949 Just before the column headers, a statement appears indicating
950 how much time each sample counted as.
951 This @dfn{sampling period} estimates the margin of error in each of the time
952 figures. A time figure that is not much larger than this is not
953 reliable. In this example, each sample counted as 0.01 seconds,
954 suggesting a 100 Hz sampling rate.
955 The program's total execution time was 0.06
956 seconds, as indicated by the @samp{cumulative seconds} field. Since
957 each sample counted for 0.01 seconds, this means only six samples
958 were taken during the run. Two of the samples occurred while the
959 program was in the @samp{open} function, as indicated by the
960 @samp{self seconds} field. Each of the other four samples
961 occurred one each in @samp{offtime}, @samp{memccpy}, @samp{write},
963 Since only six samples were taken, none of these values can
964 be regarded as particularly reliable.
966 the @samp{self seconds} field for
967 @samp{mcount} might well be @samp{0.00} or @samp{0.02}.
968 @xref{Sampling Error, ,Statistical Sampling Error},
969 for a complete discussion.
971 The remaining functions in the listing (those whose
972 @samp{self seconds} field is @samp{0.00}) didn't appear
973 in the histogram samples at all. However, the call graph
974 indicated that they were called, so therefore they are listed,
975 sorted in decreasing order by the @samp{calls} field.
976 Clearly some time was spent executing these functions,
977 but the paucity of histogram samples prevents any
978 determination of how much time each took.
980 Here is what the fields in each line mean:
984 This is the percentage of the total execution time your program spent
985 in this function. These should all add up to 100%.
987 @item cumulative seconds
988 This is the cumulative total number of seconds the computer spent
989 executing this functions, plus the time spent in all the functions
990 above this one in this table.
993 This is the number of seconds accounted for by this function alone.
994 The flat profile listing is sorted first by this number.
997 This is the total number of times the function was called. If the
998 function was never called, or the number of times it was called cannot
999 be determined (probably because the function was not compiled with
1000 profiling enabled), the @dfn{calls} field is blank.
1003 This represents the average number of milliseconds spent in this
1004 function per call, if this function is profiled. Otherwise, this field
1005 is blank for this function.
1008 This represents the average number of milliseconds spent in this
1009 function and its descendants per call, if this function is profiled.
1010 Otherwise, this field is blank for this function.
1011 This is the only field in the flat profile that uses call graph analysis.
1014 This is the name of the function. The flat profile is sorted by this
1015 field alphabetically after the @dfn{self seconds} and @dfn{calls}
1020 @section The Call Graph
1023 The @dfn{call graph} shows how much time was spent in each function
1024 and its children. From this information, you can find functions that,
1025 while they themselves may not have used much time, called other
1026 functions that did use unusual amounts of time.
1028 Here is a sample call from a small program. This call came from the
1029 same @code{gprof} run as the flat profile example in the previous
1034 granularity: each sample hit covers 2 byte(s) for 20.00% of 0.05 seconds
1036 index % time self children called name
1038 [1] 100.0 0.00 0.05 start [1]
1039 0.00 0.05 1/1 main [2]
1040 0.00 0.00 1/2 on_exit [28]
1041 0.00 0.00 1/1 exit [59]
1042 -----------------------------------------------
1043 0.00 0.05 1/1 start [1]
1044 [2] 100.0 0.00 0.05 1 main [2]
1045 0.00 0.05 1/1 report [3]
1046 -----------------------------------------------
1047 0.00 0.05 1/1 main [2]
1048 [3] 100.0 0.00 0.05 1 report [3]
1049 0.00 0.03 8/8 timelocal [6]
1050 0.00 0.01 1/1 print [9]
1051 0.00 0.01 9/9 fgets [12]
1052 0.00 0.00 12/34 strncmp <cycle 1> [40]
1053 0.00 0.00 8/8 lookup [20]
1054 0.00 0.00 1/1 fopen [21]
1055 0.00 0.00 8/8 chewtime [24]
1056 0.00 0.00 8/16 skipspace [44]
1057 -----------------------------------------------
1058 [4] 59.8 0.01 0.02 8+472 <cycle 2 as a whole> [4]
1059 0.01 0.02 244+260 offtime <cycle 2> [7]
1060 0.00 0.00 236+1 tzset <cycle 2> [26]
1061 -----------------------------------------------
1065 The lines full of dashes divide this table into @dfn{entries}, one for each
1066 function. Each entry has one or more lines.
1068 In each entry, the primary line is the one that starts with an index number
1069 in square brackets. The end of this line says which function the entry is
1070 for. The preceding lines in the entry describe the callers of this
1071 function and the following lines describe its subroutines (also called
1072 @dfn{children} when we speak of the call graph).
1074 The entries are sorted by time spent in the function and its subroutines.
1076 The internal profiling function @code{mcount} (@pxref{Flat Profile, ,The
1077 Flat Profile}) is never mentioned in the call graph.
1080 * Primary:: Details of the primary line's contents.
1081 * Callers:: Details of caller-lines' contents.
1082 * Subroutines:: Details of subroutine-lines' contents.
1083 * Cycles:: When there are cycles of recursion,
1084 such as @code{a} calls @code{b} calls @code{a}@dots{}
1088 @subsection The Primary Line
1090 The @dfn{primary line} in a call graph entry is the line that
1091 describes the function which the entry is about and gives the overall
1092 statistics for this function.
1094 For reference, we repeat the primary line from the entry for function
1095 @code{report} in our main example, together with the heading line that
1096 shows the names of the fields:
1100 index % time self children called name
1102 [3] 100.0 0.00 0.05 1 report [3]
1106 Here is what the fields in the primary line mean:
1110 Entries are numbered with consecutive integers. Each function
1111 therefore has an index number, which appears at the beginning of its
1114 Each cross-reference to a function, as a caller or subroutine of
1115 another, gives its index number as well as its name. The index number
1116 guides you if you wish to look for the entry for that function.
1119 This is the percentage of the total time that was spent in this
1120 function, including time spent in subroutines called from this
1123 The time spent in this function is counted again for the callers of
1124 this function. Therefore, adding up these percentages is meaningless.
1127 This is the total amount of time spent in this function. This
1128 should be identical to the number printed in the @code{seconds} field
1129 for this function in the flat profile.
1132 This is the total amount of time spent in the subroutine calls made by
1133 this function. This should be equal to the sum of all the @code{self}
1134 and @code{children} entries of the children listed directly below this
1138 This is the number of times the function was called.
1140 If the function called itself recursively, there are two numbers,
1141 separated by a @samp{+}. The first number counts non-recursive calls,
1142 and the second counts recursive calls.
1144 In the example above, the function @code{report} was called once from
1148 This is the name of the current function. The index number is
1151 If the function is part of a cycle of recursion, the cycle number is
1152 printed between the function's name and the index number
1153 (@pxref{Cycles, ,How Mutually Recursive Functions Are Described}).
1154 For example, if function @code{gnurr} is part of
1155 cycle number one, and has index number twelve, its primary line would
1159 gnurr <cycle 1> [12]
1164 @subsection Lines for a Function's Callers
1166 A function's entry has a line for each function it was called by.
1167 These lines' fields correspond to the fields of the primary line, but
1168 their meanings are different because of the difference in context.
1170 For reference, we repeat two lines from the entry for the function
1171 @code{report}, the primary line and one caller-line preceding it, together
1172 with the heading line that shows the names of the fields:
1175 index % time self children called name
1177 0.00 0.05 1/1 main [2]
1178 [3] 100.0 0.00 0.05 1 report [3]
1181 Here are the meanings of the fields in the caller-line for @code{report}
1182 called from @code{main}:
1186 An estimate of the amount of time spent in @code{report} itself when it was
1187 called from @code{main}.
1190 An estimate of the amount of time spent in subroutines of @code{report}
1191 when @code{report} was called from @code{main}.
1193 The sum of the @code{self} and @code{children} fields is an estimate
1194 of the amount of time spent within calls to @code{report} from @code{main}.
1197 Two numbers: the number of times @code{report} was called from @code{main},
1198 followed by the total number of non-recursive calls to @code{report} from
1201 @item name and index number
1202 The name of the caller of @code{report} to which this line applies,
1203 followed by the caller's index number.
1205 Not all functions have entries in the call graph; some
1206 options to @code{gprof} request the omission of certain functions.
1207 When a caller has no entry of its own, it still has caller-lines
1208 in the entries of the functions it calls.
1210 If the caller is part of a recursion cycle, the cycle number is
1211 printed between the name and the index number.
1214 If the identity of the callers of a function cannot be determined, a
1215 dummy caller-line is printed which has @samp{<spontaneous>} as the
1216 ``caller's name'' and all other fields blank. This can happen for
1218 @c What if some calls have determinable callers' names but not all?
1219 @c FIXME - still relevant?
1222 @subsection Lines for a Function's Subroutines
1224 A function's entry has a line for each of its subroutines---in other
1225 words, a line for each other function that it called. These lines'
1226 fields correspond to the fields of the primary line, but their meanings
1227 are different because of the difference in context.
1229 For reference, we repeat two lines from the entry for the function
1230 @code{main}, the primary line and a line for a subroutine, together
1231 with the heading line that shows the names of the fields:
1234 index % time self children called name
1236 [2] 100.0 0.00 0.05 1 main [2]
1237 0.00 0.05 1/1 report [3]
1240 Here are the meanings of the fields in the subroutine-line for @code{main}
1241 calling @code{report}:
1245 An estimate of the amount of time spent directly within @code{report}
1246 when @code{report} was called from @code{main}.
1249 An estimate of the amount of time spent in subroutines of @code{report}
1250 when @code{report} was called from @code{main}.
1252 The sum of the @code{self} and @code{children} fields is an estimate
1253 of the total time spent in calls to @code{report} from @code{main}.
1256 Two numbers, the number of calls to @code{report} from @code{main}
1257 followed by the total number of non-recursive calls to @code{report}.
1258 This ratio is used to determine how much of @code{report}'s @code{self}
1259 and @code{children} time gets credited to @code{main}.
1260 @xref{Assumptions, ,Estimating @code{children} Times}.
1263 The name of the subroutine of @code{main} to which this line applies,
1264 followed by the subroutine's index number.
1266 If the caller is part of a recursion cycle, the cycle number is
1267 printed between the name and the index number.
1271 @subsection How Mutually Recursive Functions Are Described
1273 @cindex recursion cycle
1275 The graph may be complicated by the presence of @dfn{cycles of
1276 recursion} in the call graph. A cycle exists if a function calls
1277 another function that (directly or indirectly) calls (or appears to
1278 call) the original function. For example: if @code{a} calls @code{b},
1279 and @code{b} calls @code{a}, then @code{a} and @code{b} form a cycle.
1281 Whenever there are call paths both ways between a pair of functions, they
1282 belong to the same cycle. If @code{a} and @code{b} call each other and
1283 @code{b} and @code{c} call each other, all three make one cycle. Note that
1284 even if @code{b} only calls @code{a} if it was not called from @code{a},
1285 @code{gprof} cannot determine this, so @code{a} and @code{b} are still
1288 The cycles are numbered with consecutive integers. When a function
1289 belongs to a cycle, each time the function name appears in the call graph
1290 it is followed by @samp{<cycle @var{number}>}.
1292 The reason cycles matter is that they make the time values in the call
1293 graph paradoxical. The ``time spent in children'' of @code{a} should
1294 include the time spent in its subroutine @code{b} and in @code{b}'s
1295 subroutines---but one of @code{b}'s subroutines is @code{a}! How much of
1296 @code{a}'s time should be included in the children of @code{a}, when
1297 @code{a} is indirectly recursive?
1299 The way @code{gprof} resolves this paradox is by creating a single entry
1300 for the cycle as a whole. The primary line of this entry describes the
1301 total time spent directly in the functions of the cycle. The
1302 ``subroutines'' of the cycle are the individual functions of the cycle, and
1303 all other functions that were called directly by them. The ``callers'' of
1304 the cycle are the functions, outside the cycle, that called functions in
1307 Here is an example portion of a call graph which shows a cycle containing
1308 functions @code{a} and @code{b}. The cycle was entered by a call to
1309 @code{a} from @code{main}; both @code{a} and @code{b} called @code{c}.
1312 index % time self children called name
1313 ----------------------------------------
1315 [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3]
1316 1.02 0 3 b <cycle 1> [4]
1317 0.75 0 2 a <cycle 1> [5]
1318 ----------------------------------------
1320 [4] 52.85 1.02 0 0 b <cycle 1> [4]
1323 ----------------------------------------
1326 [5] 38.86 0.75 0 1 a <cycle 1> [5]
1329 ----------------------------------------
1333 (The entire call graph for this program contains in addition an entry for
1334 @code{main}, which calls @code{a}, and an entry for @code{c}, with callers
1335 @code{a} and @code{b}.)
1338 index % time self children called name
1340 [1] 100.00 0 1.93 0 start [1]
1341 0.16 1.77 1/1 main [2]
1342 ----------------------------------------
1343 0.16 1.77 1/1 start [1]
1344 [2] 100.00 0.16 1.77 1 main [2]
1345 1.77 0 1/1 a <cycle 1> [5]
1346 ----------------------------------------
1348 [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3]
1349 1.02 0 3 b <cycle 1> [4]
1350 0.75 0 2 a <cycle 1> [5]
1352 ----------------------------------------
1354 [4] 52.85 1.02 0 0 b <cycle 1> [4]
1357 ----------------------------------------
1360 [5] 38.86 0.75 0 1 a <cycle 1> [5]
1363 ----------------------------------------
1364 0 0 3/6 b <cycle 1> [4]
1365 0 0 3/6 a <cycle 1> [5]
1366 [6] 0.00 0 0 6 c [6]
1367 ----------------------------------------
1370 The @code{self} field of the cycle's primary line is the total time
1371 spent in all the functions of the cycle. It equals the sum of the
1372 @code{self} fields for the individual functions in the cycle, found
1373 in the entry in the subroutine lines for these functions.
1375 The @code{children} fields of the cycle's primary line and subroutine lines
1376 count only subroutines outside the cycle. Even though @code{a} calls
1377 @code{b}, the time spent in those calls to @code{b} is not counted in
1378 @code{a}'s @code{children} time. Thus, we do not encounter the problem of
1379 what to do when the time in those calls to @code{b} includes indirect
1380 recursive calls back to @code{a}.
1382 The @code{children} field of a caller-line in the cycle's entry estimates
1383 the amount of time spent @emph{in the whole cycle}, and its other
1384 subroutines, on the times when that caller called a function in the cycle.
1386 The @code{called} field in the primary line for the cycle has two numbers:
1387 first, the number of times functions in the cycle were called by functions
1388 outside the cycle; second, the number of times they were called by
1389 functions in the cycle (including times when a function in the cycle calls
1390 itself). This is a generalization of the usual split into non-recursive and
1393 The @code{called} field of a subroutine-line for a cycle member in the
1394 cycle's entry says how many time that function was called from functions in
1395 the cycle. The total of all these is the second number in the primary line's
1396 @code{called} field.
1398 In the individual entry for a function in a cycle, the other functions in
1399 the same cycle can appear as subroutines and as callers. These lines show
1400 how many times each function in the cycle called or was called from each other
1401 function in the cycle. The @code{self} and @code{children} fields in these
1402 lines are blank because of the difficulty of defining meanings for them
1403 when recursion is going on.
1406 @section Line-by-line Profiling
1408 @code{gprof}'s @samp{-l} option causes the program to perform
1409 @dfn{line-by-line} profiling. In this mode, histogram
1410 samples are assigned not to functions, but to individual
1411 lines of source code. The program usually must be compiled
1412 with a @samp{-g} option, in addition to @samp{-pg}, in order
1413 to generate debugging symbols for tracking source code lines.
1415 The flat profile is the most useful output table
1416 in line-by-line mode.
1417 The call graph isn't as useful as normal, since
1418 the current version of @code{gprof} does not propagate
1419 call graph arcs from source code lines to the enclosing function.
1420 The call graph does, however, show each line of code
1421 that called each function, along with a count.
1423 Here is a section of @code{gprof}'s output, without line-by-line profiling.
1424 Note that @code{ct_init} accounted for four histogram hits, and
1425 13327 calls to @code{init_block}.
1430 Each sample counts as 0.01 seconds.
1431 % cumulative self self total
1432 time seconds seconds calls us/call us/call name
1433 30.77 0.13 0.04 6335 6.31 6.31 ct_init
1436 Call graph (explanation follows)
1439 granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds
1441 index % time self children called name
1443 0.00 0.00 1/13496 name_too_long
1444 0.00 0.00 40/13496 deflate
1445 0.00 0.00 128/13496 deflate_fast
1446 0.00 0.00 13327/13496 ct_init
1447 [7] 0.0 0.00 0.00 13496 init_block
1451 Now let's look at some of @code{gprof}'s output from the same program run,
1452 this time with line-by-line profiling enabled. Note that @code{ct_init}'s
1453 four histogram hits are broken down into four lines of source code---one hit
1454 occurred on each of lines 349, 351, 382 and 385. In the call graph,
1456 @code{ct_init}'s 13327 calls to @code{init_block} are broken down
1457 into one call from line 396, 3071 calls from line 384, 3730 calls
1458 from line 385, and 6525 calls from 387.
1463 Each sample counts as 0.01 seconds.
1465 time seconds seconds calls name
1466 7.69 0.10 0.01 ct_init (trees.c:349)
1467 7.69 0.11 0.01 ct_init (trees.c:351)
1468 7.69 0.12 0.01 ct_init (trees.c:382)
1469 7.69 0.13 0.01 ct_init (trees.c:385)
1472 Call graph (explanation follows)
1475 granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds
1477 % time self children called name
1479 0.00 0.00 1/13496 name_too_long (gzip.c:1440)
1480 0.00 0.00 1/13496 deflate (deflate.c:763)
1481 0.00 0.00 1/13496 ct_init (trees.c:396)
1482 0.00 0.00 2/13496 deflate (deflate.c:727)
1483 0.00 0.00 4/13496 deflate (deflate.c:686)
1484 0.00 0.00 5/13496 deflate (deflate.c:675)
1485 0.00 0.00 12/13496 deflate (deflate.c:679)
1486 0.00 0.00 16/13496 deflate (deflate.c:730)
1487 0.00 0.00 128/13496 deflate_fast (deflate.c:654)
1488 0.00 0.00 3071/13496 ct_init (trees.c:384)
1489 0.00 0.00 3730/13496 ct_init (trees.c:385)
1490 0.00 0.00 6525/13496 ct_init (trees.c:387)
1491 [6] 0.0 0.00 0.00 13496 init_block (trees.c:408)
1496 @node Annotated Source
1497 @section The Annotated Source Listing
1499 @code{gprof}'s @samp{-A} option triggers an annotated source listing,
1500 which lists the program's source code, each function labeled with the
1501 number of times it was called. You may also need to specify the
1502 @samp{-I} option, if @code{gprof} can't find the source code files.
1504 Compiling with @samp{gcc @dots{} -g -pg -a} augments your program
1505 with basic-block counting code, in addition to function counting code.
1506 This enables @code{gprof} to determine how many times each line
1507 of code was executed.
1508 For example, consider the following function, taken from gzip,
1509 with line numbers added:
1518 7 static ulg crc = (ulg)0xffffffffL;
1525 14 c = crc_32_tab[...];
1529 18 return c ^ 0xffffffffL;
1534 @code{updcrc} has at least five basic-blocks.
1535 One is the function itself. The
1536 @code{if} statement on line 9 generates two more basic-blocks, one
1537 for each branch of the @code{if}. A fourth basic-block results from
1538 the @code{if} on line 13, and the contents of the @code{do} loop form
1539 the fifth basic-block. The compiler may also generate additional
1540 basic-blocks to handle various special cases.
1542 A program augmented for basic-block counting can be analyzed with
1544 The @samp{-x} option is also helpful,
1545 to ensure that each line of code is labeled at least once.
1546 Here is @code{updcrc}'s
1547 annotated source listing for a sample @code{gzip} run:
1556 static ulg crc = (ulg)0xffffffffL;
1558 2 -> if (s == NULL) @{
1559 1 -> c = 0xffffffffL;
1563 26312 -> c = crc_32_tab[...];
1564 26312,1,26311 -> @} while (--n);
1567 2 -> return c ^ 0xffffffffL;
1571 In this example, the function was called twice, passing once through
1572 each branch of the @code{if} statement. The body of the @code{do}
1573 loop was executed a total of 26312 times. Note how the @code{while}
1574 statement is annotated. It began execution 26312 times, once for
1575 each iteration through the loop. One of those times (the last time)
1576 it exited, while it branched back to the beginning of the loop 26311 times.
1579 @chapter Inaccuracy of @code{gprof} Output
1582 * Sampling Error:: Statistical margins of error
1583 * Assumptions:: Estimating children times
1586 @node Sampling Error
1587 @section Statistical Sampling Error
1589 The run-time figures that @code{gprof} gives you are based on a sampling
1590 process, so they are subject to statistical inaccuracy. If a function runs
1591 only a small amount of time, so that on the average the sampling process
1592 ought to catch that function in the act only once, there is a pretty good
1593 chance it will actually find that function zero times, or twice.
1595 By contrast, the number-of-calls and basic-block figures
1596 are derived by counting, not
1597 sampling. They are completely accurate and will not vary from run to run
1598 if your program is deterministic.
1600 The @dfn{sampling period} that is printed at the beginning of the flat
1601 profile says how often samples are taken. The rule of thumb is that a
1602 run-time figure is accurate if it is considerably bigger than the sampling
1605 The actual amount of error can be predicted.
1606 For @var{n} samples, the @emph{expected} error
1607 is the square-root of @var{n}. For example,
1608 if the sampling period is 0.01 seconds and @code{foo}'s run-time is 1 second,
1609 @var{n} is 100 samples (1 second/0.01 seconds), sqrt(@var{n}) is 10 samples, so
1610 the expected error in @code{foo}'s run-time is 0.1 seconds (10*0.01 seconds),
1611 or ten percent of the observed value.
1612 Again, if the sampling period is 0.01 seconds and @code{bar}'s run-time is
1613 100 seconds, @var{n} is 10000 samples, sqrt(@var{n}) is 100 samples, so
1614 the expected error in @code{bar}'s run-time is 1 second,
1615 or one percent of the observed value.
1617 vary this much @emph{on the average} from one profiling run to the next.
1618 (@emph{Sometimes} it will vary more.)
1620 This does not mean that a small run-time figure is devoid of information.
1621 If the program's @emph{total} run-time is large, a small run-time for one
1622 function does tell you that that function used an insignificant fraction of
1623 the whole program's time. Usually this means it is not worth optimizing.
1625 One way to get more accuracy is to give your program more (but similar)
1626 input data so it will take longer. Another way is to combine the data from
1627 several runs, using the @samp{-s} option of @code{gprof}. Here is how:
1631 Run your program once.
1634 Issue the command @samp{mv gmon.out gmon.sum}.
1637 Run your program again, the same as before.
1640 Merge the new data in @file{gmon.out} into @file{gmon.sum} with this command:
1643 gprof -s @var{executable-file} gmon.out gmon.sum
1647 Repeat the last two steps as often as you wish.
1650 Analyze the cumulative data using this command:
1653 gprof @var{executable-file} gmon.sum > @var{output-file}
1658 @section Estimating @code{children} Times
1660 Some of the figures in the call graph are estimates---for example, the
1661 @code{children} time values and all the time figures in caller and
1664 There is no direct information about these measurements in the profile
1665 data itself. Instead, @code{gprof} estimates them by making an assumption
1666 about your program that might or might not be true.
1668 The assumption made is that the average time spent in each call to any
1669 function @code{foo} is not correlated with who called @code{foo}. If
1670 @code{foo} used 5 seconds in all, and 2/5 of the calls to @code{foo} came
1671 from @code{a}, then @code{foo} contributes 2 seconds to @code{a}'s
1672 @code{children} time, by assumption.
1674 This assumption is usually true enough, but for some programs it is far
1675 from true. Suppose that @code{foo} returns very quickly when its argument
1676 is zero; suppose that @code{a} always passes zero as an argument, while
1677 other callers of @code{foo} pass other arguments. In this program, all the
1678 time spent in @code{foo} is in the calls from callers other than @code{a}.
1679 But @code{gprof} has no way of knowing this; it will blindly and
1680 incorrectly charge 2 seconds of time in @code{foo} to the children of
1683 @c FIXME - has this been fixed?
1684 We hope some day to put more complete data into @file{gmon.out}, so that
1685 this assumption is no longer needed, if we can figure out how. For the
1686 novice, the estimated figures are usually more useful than misleading.
1689 @chapter Answers to Common Questions
1692 @item How can I get more exact information about hot spots in my program?
1694 Looking at the per-line call counts only tells part of the story.
1695 Because @code{gprof} can only report call times and counts by function,
1696 the best way to get finer-grained information on where the program
1697 is spending its time is to re-factor large functions into sequences
1698 of calls to smaller ones. Beware however that this can introduce
1699 artificial hot spots since compiling with @samp{-pg} adds a significant
1700 overhead to function calls. An alternative solution is to use a
1701 non-intrusive profiler, e.g.@: oprofile.
1703 @item How do I find which lines in my program were executed the most times?
1705 Compile your program with basic-block counting enabled, run it, then
1706 use the following pipeline:
1709 gprof -l -C @var{objfile} | sort -k 3 -n -r
1712 This listing will show you the lines in your code executed most often,
1713 but not necessarily those that consumed the most time.
1715 @item How do I find which lines in my program called a particular function?
1717 Use @samp{gprof -l} and lookup the function in the call graph.
1718 The callers will be broken down by function and line number.
1720 @item How do I analyze a program that runs for less than a second?
1722 Try using a shell script like this one:
1725 for i in `seq 1 100`; do
1727 mv gmon.out gmon.out.$i
1730 gprof -s fastprog gmon.out.*
1732 gprof fastprog gmon.sum
1735 If your program is completely deterministic, all the call counts
1736 will be simple multiples of 100 (i.e., a function called once in
1737 each run will appear with a call count of 100).
1741 @node Incompatibilities
1742 @chapter Incompatibilities with Unix @code{gprof}
1744 @sc{gnu} @code{gprof} and Berkeley Unix @code{gprof} use the same data
1745 file @file{gmon.out}, and provide essentially the same information. But
1746 there are a few differences.
1750 @sc{gnu} @code{gprof} uses a new, generalized file format with support
1751 for basic-block execution counts and non-realtime histograms. A magic
1752 cookie and version number allows @code{gprof} to easily identify
1753 new style files. Old BSD-style files can still be read.
1754 @xref{File Format, ,Profiling Data File Format}.
1757 For a recursive function, Unix @code{gprof} lists the function as a
1758 parent and as a child, with a @code{calls} field that lists the number
1759 of recursive calls. @sc{gnu} @code{gprof} omits these lines and puts
1760 the number of recursive calls in the primary line.
1763 When a function is suppressed from the call graph with @samp{-e}, @sc{gnu}
1764 @code{gprof} still lists it as a subroutine of functions that call it.
1767 @sc{gnu} @code{gprof} accepts the @samp{-k} with its argument
1768 in the form @samp{from/to}, instead of @samp{from to}.
1771 In the annotated source listing,
1772 if there are multiple basic blocks on the same line,
1773 @sc{gnu} @code{gprof} prints all of their counts, separated by commas.
1775 @ignore - it does this now
1777 The function names printed in @sc{gnu} @code{gprof} output do not include
1778 the leading underscores that are added internally to the front of all
1779 C identifiers on many operating systems.
1783 The blurbs, field widths, and output formats are different. @sc{gnu}
1784 @code{gprof} prints blurbs after the tables, so that you can see the
1785 tables without skipping the blurbs.
1789 @chapter Details of Profiling
1792 * Implementation:: How a program collects profiling information
1793 * File Format:: Format of @samp{gmon.out} files
1794 * Internals:: @code{gprof}'s internal operation
1795 * Debugging:: Using @code{gprof}'s @samp{-d} option
1798 @node Implementation
1799 @section Implementation of Profiling
1801 Profiling works by changing how every function in your program is compiled
1802 so that when it is called, it will stash away some information about where
1803 it was called from. From this, the profiler can figure out what function
1804 called it, and can count how many times it was called. This change is made
1805 by the compiler when your program is compiled with the @samp{-pg} option,
1806 which causes every function to call @code{mcount}
1807 (or @code{_mcount}, or @code{__mcount}, depending on the OS and compiler)
1808 as one of its first operations.
1810 The @code{mcount} routine, included in the profiling library,
1811 is responsible for recording in an in-memory call graph table
1812 both its parent routine (the child) and its parent's parent. This is
1813 typically done by examining the stack frame to find both
1814 the address of the child, and the return address in the original parent.
1815 Since this is a very machine-dependent operation, @code{mcount}
1816 itself is typically a short assembly-language stub routine
1817 that extracts the required
1818 information, and then calls @code{__mcount_internal}
1819 (a normal C function) with two arguments---@code{frompc} and @code{selfpc}.
1820 @code{__mcount_internal} is responsible for maintaining
1821 the in-memory call graph, which records @code{frompc}, @code{selfpc},
1822 and the number of times each of these call arcs was traversed.
1824 GCC Version 2 provides a magical function (@code{__builtin_return_address}),
1825 which allows a generic @code{mcount} function to extract the
1826 required information from the stack frame. However, on some
1827 architectures, most notably the SPARC, using this builtin can be
1828 very computationally expensive, and an assembly language version
1829 of @code{mcount} is used for performance reasons.
1831 Number-of-calls information for library routines is collected by using a
1832 special version of the C library. The programs in it are the same as in
1833 the usual C library, but they were compiled with @samp{-pg}. If you
1834 link your program with @samp{gcc @dots{} -pg}, it automatically uses the
1835 profiling version of the library.
1837 Profiling also involves watching your program as it runs, and keeping a
1838 histogram of where the program counter happens to be every now and then.
1839 Typically the program counter is looked at around 100 times per second of
1840 run time, but the exact frequency may vary from system to system.
1842 This is done is one of two ways. Most UNIX-like operating systems
1843 provide a @code{profil()} system call, which registers a memory
1844 array with the kernel, along with a scale
1845 factor that determines how the program's address space maps
1847 Typical scaling values cause every 2 to 8 bytes of address space
1848 to map into a single array slot.
1849 On every tick of the system clock
1850 (assuming the profiled program is running), the value of the
1851 program counter is examined and the corresponding slot in
1852 the memory array is incremented. Since this is done in the kernel,
1853 which had to interrupt the process anyway to handle the clock
1854 interrupt, very little additional system overhead is required.
1856 However, some operating systems, most notably Linux 2.0 (and earlier),
1857 do not provide a @code{profil()} system call. On such a system,
1858 arrangements are made for the kernel to periodically deliver
1859 a signal to the process (typically via @code{setitimer()}),
1860 which then performs the same operation of examining the
1861 program counter and incrementing a slot in the memory array.
1862 Since this method requires a signal to be delivered to
1863 user space every time a sample is taken, it uses considerably
1864 more overhead than kernel-based profiling. Also, due to the
1865 added delay required to deliver the signal, this method is
1866 less accurate as well.
1868 A special startup routine allocates memory for the histogram and
1869 either calls @code{profil()} or sets up
1870 a clock signal handler.
1871 This routine (@code{monstartup}) can be invoked in several ways.
1872 On Linux systems, a special profiling startup file @code{gcrt0.o},
1873 which invokes @code{monstartup} before @code{main},
1874 is used instead of the default @code{crt0.o}.
1875 Use of this special startup file is one of the effects
1876 of using @samp{gcc @dots{} -pg} to link.
1877 On SPARC systems, no special startup files are used.
1878 Rather, the @code{mcount} routine, when it is invoked for
1879 the first time (typically when @code{main} is called),
1880 calls @code{monstartup}.
1882 If the compiler's @samp{-a} option was used, basic-block counting
1883 is also enabled. Each object file is then compiled with a static array
1884 of counts, initially zero.
1885 In the executable code, every time a new basic-block begins
1886 (i.e., when an @code{if} statement appears), an extra instruction
1887 is inserted to increment the corresponding count in the array.
1888 At compile time, a paired array was constructed that recorded
1889 the starting address of each basic-block. Taken together,
1890 the two arrays record the starting address of every basic-block,
1891 along with the number of times it was executed.
1893 The profiling library also includes a function (@code{mcleanup}) which is
1894 typically registered using @code{atexit()} to be called as the
1895 program exits, and is responsible for writing the file @file{gmon.out}.
1896 Profiling is turned off, various headers are output, and the histogram
1897 is written, followed by the call-graph arcs and the basic-block counts.
1899 The output from @code{gprof} gives no indication of parts of your program that
1900 are limited by I/O or swapping bandwidth. This is because samples of the
1901 program counter are taken at fixed intervals of the program's run time.
1903 time measurements in @code{gprof} output say nothing about time that your
1904 program was not running. For example, a part of the program that creates
1905 so much data that it cannot all fit in physical memory at once may run very
1906 slowly due to thrashing, but @code{gprof} will say it uses little time. On
1907 the other hand, sampling by run time has the advantage that the amount of
1908 load due to other users won't directly affect the output you get.
1911 @section Profiling Data File Format
1913 The old BSD-derived file format used for profile data does not contain a
1914 magic cookie that allows to check whether a data file really is a
1915 @code{gprof} file. Furthermore, it does not provide a version number, thus
1916 rendering changes to the file format almost impossible. @sc{gnu} @code{gprof}
1917 uses a new file format that provides these features. For backward
1918 compatibility, @sc{gnu} @code{gprof} continues to support the old BSD-derived
1919 format, but not all features are supported with it. For example,
1920 basic-block execution counts cannot be accommodated by the old file
1923 The new file format is defined in header file @file{gmon_out.h}. It
1924 consists of a header containing the magic cookie and a version number,
1925 as well as some spare bytes available for future extensions. All data
1926 in a profile data file is in the native format of the target for which
1927 the profile was collected. @sc{gnu} @code{gprof} adapts automatically
1928 to the byte-order in use.
1930 In the new file format, the header is followed by a sequence of
1931 records. Currently, there are three different record types: histogram
1932 records, call-graph arc records, and basic-block execution count
1933 records. Each file can contain any number of each record type. When
1934 reading a file, @sc{gnu} @code{gprof} will ensure records of the same type are
1935 compatible with each other and compute the union of all records. For
1936 example, for basic-block execution counts, the union is simply the sum
1937 of all execution counts for each basic-block.
1939 @subsection Histogram Records
1941 Histogram records consist of a header that is followed by an array of
1942 bins. The header contains the text-segment range that the histogram
1943 spans, the size of the histogram in bytes (unlike in the old BSD
1944 format, this does not include the size of the header), the rate of the
1945 profiling clock, and the physical dimension that the bin counts
1946 represent after being scaled by the profiling clock rate. The
1947 physical dimension is specified in two parts: a long name of up to 15
1948 characters and a single character abbreviation. For example, a
1949 histogram representing real-time would specify the long name as
1950 ``seconds'' and the abbreviation as ``s''. This feature is useful for
1951 architectures that support performance monitor hardware (which,
1952 fortunately, is becoming increasingly common). For example, under DEC
1953 OSF/1, the ``uprofile'' command can be used to produce a histogram of,
1954 say, instruction cache misses. In this case, the dimension in the
1955 histogram header could be set to ``i-cache misses'' and the abbreviation
1956 could be set to ``1'' (because it is simply a count, not a physical
1957 dimension). Also, the profiling rate would have to be set to 1 in
1960 Histogram bins are 16-bit numbers and each bin represent an equal
1961 amount of text-space. For example, if the text-segment is one
1962 thousand bytes long and if there are ten bins in the histogram, each
1963 bin represents one hundred bytes.
1966 @subsection Call-Graph Records
1968 Call-graph records have a format that is identical to the one used in
1969 the BSD-derived file format. It consists of an arc in the call graph
1970 and a count indicating the number of times the arc was traversed
1971 during program execution. Arcs are specified by a pair of addresses:
1972 the first must be within caller's function and the second must be
1973 within the callee's function. When performing profiling at the
1974 function level, these addresses can point anywhere within the
1975 respective function. However, when profiling at the line-level, it is
1976 better if the addresses are as close to the call-site/entry-point as
1977 possible. This will ensure that the line-level call-graph is able to
1978 identify exactly which line of source code performed calls to a
1981 @subsection Basic-Block Execution Count Records
1983 Basic-block execution count records consist of a header followed by a
1984 sequence of address/count pairs. The header simply specifies the
1985 length of the sequence. In an address/count pair, the address
1986 identifies a basic-block and the count specifies the number of times
1987 that basic-block was executed. Any address within the basic-address can
1991 @section @code{gprof}'s Internal Operation
1993 Like most programs, @code{gprof} begins by processing its options.
1994 During this stage, it may building its symspec list
1995 (@code{sym_ids.c:@-sym_id_add}), if
1996 options are specified which use symspecs.
1997 @code{gprof} maintains a single linked list of symspecs,
1998 which will eventually get turned into 12 symbol tables,
1999 organized into six include/exclude pairs---one
2000 pair each for the flat profile (INCL_FLAT/EXCL_FLAT),
2001 the call graph arcs (INCL_ARCS/EXCL_ARCS),
2002 printing in the call graph (INCL_GRAPH/EXCL_GRAPH),
2003 timing propagation in the call graph (INCL_TIME/EXCL_TIME),
2004 the annotated source listing (INCL_ANNO/EXCL_ANNO),
2005 and the execution count listing (INCL_EXEC/EXCL_EXEC).
2007 After option processing, @code{gprof} finishes
2008 building the symspec list by adding all the symspecs in
2009 @code{default_excluded_list} to the exclude lists
2010 EXCL_TIME and EXCL_GRAPH, and if line-by-line profiling is specified,
2012 These default excludes are not added to EXCL_ANNO, EXCL_ARCS, and EXCL_EXEC.
2014 Next, the BFD library is called to open the object file,
2015 verify that it is an object file,
2016 and read its symbol table (@code{core.c:@-core_init}),
2017 using @code{bfd_canonicalize_symtab} after mallocing
2018 an appropriately sized array of symbols. At this point,
2019 function mappings are read (if the @samp{--file-ordering} option
2020 has been specified), and the core text space is read into
2021 memory (if the @samp{-c} option was given).
2023 @code{gprof}'s own symbol table, an array of Sym structures,
2025 This is done in one of two ways, by one of two routines, depending
2026 on whether line-by-line profiling (@samp{-l} option) has been
2028 For normal profiling, the BFD canonical symbol table is scanned.
2029 For line-by-line profiling, every
2030 text space address is examined, and a new symbol table entry
2031 gets created every time the line number changes.
2032 In either case, two passes are made through the symbol
2033 table---one to count the size of the symbol table required,
2034 and the other to actually read the symbols. In between the
2035 two passes, a single array of type @code{Sym} is created of
2036 the appropriate length.
2037 Finally, @code{symtab.c:@-symtab_finalize}
2038 is called to sort the symbol table and remove duplicate entries
2039 (entries with the same memory address).
2041 The symbol table must be a contiguous array for two reasons.
2042 First, the @code{qsort} library function (which sorts an array)
2043 will be used to sort the symbol table.
2044 Also, the symbol lookup routine (@code{symtab.c:@-sym_lookup}),
2046 based on memory address, uses a binary search algorithm
2047 which requires the symbol table to be a sorted array.
2048 Function symbols are indicated with an @code{is_func} flag.
2049 Line number symbols have no special flags set.
2050 Additionally, a symbol can have an @code{is_static} flag
2051 to indicate that it is a local symbol.
2053 With the symbol table read, the symspecs can now be translated
2054 into Syms (@code{sym_ids.c:@-sym_id_parse}). Remember that a single
2055 symspec can match multiple symbols.
2056 An array of symbol tables
2057 (@code{syms}) is created, each entry of which is a symbol table
2058 of Syms to be included or excluded from a particular listing.
2059 The master symbol table and the symspecs are examined by nested
2060 loops, and every symbol that matches a symspec is inserted
2061 into the appropriate syms table. This is done twice, once to
2062 count the size of each required symbol table, and again to build
2063 the tables, which have been malloced between passes.
2064 From now on, to determine whether a symbol is on an include
2065 or exclude symspec list, @code{gprof} simply uses its
2066 standard symbol lookup routine on the appropriate table
2067 in the @code{syms} array.
2069 Now the profile data file(s) themselves are read
2070 (@code{gmon_io.c:@-gmon_out_read}),
2071 first by checking for a new-style @samp{gmon.out} header,
2072 then assuming this is an old-style BSD @samp{gmon.out}
2073 if the magic number test failed.
2075 New-style histogram records are read by @code{hist.c:@-hist_read_rec}.
2076 For the first histogram record, allocate a memory array to hold
2077 all the bins, and read them in.
2078 When multiple profile data files (or files with multiple histogram
2079 records) are read, the memory ranges of each pair of histogram records
2080 must be either equal, or non-overlapping. For each pair of histogram
2081 records, the resolution (memory region size divided by the number of
2082 bins) must be the same. The time unit must be the same for all
2083 histogram records. If the above containts are met, all histograms
2084 for the same memory range are merged.
2086 As each call graph record is read (@code{call_graph.c:@-cg_read_rec}),
2087 the parent and child addresses
2088 are matched to symbol table entries, and a call graph arc is
2089 created by @code{cg_arcs.c:@-arc_add}, unless the arc fails a symspec
2090 check against INCL_ARCS/EXCL_ARCS. As each arc is added,
2091 a linked list is maintained of the parent's child arcs, and of the child's
2093 Both the child's call count and the arc's call count are
2094 incremented by the record's call count.
2096 Basic-block records are read (@code{basic_blocks.c:@-bb_read_rec}),
2097 but only if line-by-line profiling has been selected.
2098 Each basic-block address is matched to a corresponding line
2099 symbol in the symbol table, and an entry made in the symbol's
2100 bb_addr and bb_calls arrays. Again, if multiple basic-block
2101 records are present for the same address, the call counts
2104 A gmon.sum file is dumped, if requested (@code{gmon_io.c:@-gmon_out_write}).
2106 If histograms were present in the data files, assign them to symbols
2107 (@code{hist.c:@-hist_assign_samples}) by iterating over all the sample
2108 bins and assigning them to symbols. Since the symbol table
2109 is sorted in order of ascending memory addresses, we can
2110 simple follow along in the symbol table as we make our pass
2111 over the sample bins.
2112 This step includes a symspec check against INCL_FLAT/EXCL_FLAT.
2113 Depending on the histogram
2114 scale factor, a sample bin may span multiple symbols,
2115 in which case a fraction of the sample count is allocated
2116 to each symbol, proportional to the degree of overlap.
2117 This effect is rare for normal profiling, but overlaps
2118 are more common during line-by-line profiling, and can
2119 cause each of two adjacent lines to be credited with half
2122 If call graph data is present, @code{cg_arcs.c:@-cg_assemble} is called.
2123 First, if @samp{-c} was specified, a machine-dependent
2124 routine (@code{find_call}) scans through each symbol's machine code,
2125 looking for subroutine call instructions, and adding them
2126 to the call graph with a zero call count.
2127 A topological sort is performed by depth-first numbering
2128 all the symbols (@code{cg_dfn.c:@-cg_dfn}), so that
2129 children are always numbered less than their parents,
2130 then making a array of pointers into the symbol table and sorting it into
2131 numerical order, which is reverse topological
2132 order (children appear before parents).
2133 Cycles are also detected at this point, all members
2134 of which are assigned the same topological number.
2135 Two passes are now made through this sorted array of symbol pointers.
2136 The first pass, from end to beginning (parents to children),
2137 computes the fraction of child time to propagate to each parent
2139 The print flag reflects symspec handling of INCL_GRAPH/EXCL_GRAPH,
2140 with a parent's include or exclude (print or no print) property
2141 being propagated to its children, unless they themselves explicitly appear
2142 in INCL_GRAPH or EXCL_GRAPH.
2143 A second pass, from beginning to end (children to parents) actually
2144 propagates the timings along the call graph, subject
2145 to a check against INCL_TIME/EXCL_TIME.
2146 With the print flag, fractions, and timings now stored in the symbol
2147 structures, the topological sort array is now discarded, and a
2148 new array of pointers is assembled, this time sorted by propagated time.
2150 Finally, print the various outputs the user requested, which is now fairly
2151 straightforward. The call graph (@code{cg_print.c:@-cg_print}) and
2152 flat profile (@code{hist.c:@-hist_print}) are regurgitations of values
2153 already computed. The annotated source listing
2154 (@code{basic_blocks.c:@-print_annotated_source}) uses basic-block
2155 information, if present, to label each line of code with call counts,
2156 otherwise only the function call counts are presented.
2158 The function ordering code is marginally well documented
2159 in the source code itself (@code{cg_print.c}). Basically,
2160 the functions with the most use and the most parents are
2161 placed first, followed by other functions with the most use,
2162 followed by lower use functions, followed by unused functions
2166 @section Debugging @code{gprof}
2168 If @code{gprof} was compiled with debugging enabled,
2169 the @samp{-d} option triggers debugging output
2170 (to stdout) which can be helpful in understanding its operation.
2171 The debugging number specified is interpreted as a sum of the following
2175 @item 2 - Topological sort
2176 Monitor depth-first numbering of symbols during call graph analysis
2178 Shows symbols as they are identified as cycle heads
2180 As the call graph arcs are read, show each arc and how
2181 the total calls to each function are tallied
2182 @item 32 - Call graph arc sorting
2183 Details sorting individual parents/children within each call graph entry
2184 @item 64 - Reading histogram and call graph records
2185 Shows address ranges of histograms as they are read, and each
2187 @item 128 - Symbol table
2188 Reading, classifying, and sorting the symbol table from the object file.
2189 For line-by-line profiling (@samp{-l} option), also shows line numbers
2190 being assigned to memory addresses.
2191 @item 256 - Static call graph
2192 Trace operation of @samp{-c} option
2193 @item 512 - Symbol table and arc table lookups
2194 Detail operation of lookup routines
2195 @item 1024 - Call graph propagation
2196 Shows how function times are propagated along the call graph
2197 @item 2048 - Basic-blocks
2198 Shows basic-block records as they are read from profile data
2199 (only meaningful with @samp{-l} option)
2200 @item 4096 - Symspecs
2201 Shows symspec-to-symbol pattern matching operation
2202 @item 8192 - Annotate source
2203 Tracks operation of @samp{-A} option
2206 @node GNU Free Documentation License
2207 @appendix GNU Free Documentation License
2208 @center Version 1.1, March 2000
2211 Copyright (C) 2000, 2003 Free Software Foundation, Inc.
2212 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
2214 Everyone is permitted to copy and distribute verbatim copies
2215 of this license document, but changing it is not allowed.
2222 The purpose of this License is to make a manual, textbook, or other
2223 written document ``free'' in the sense of freedom: to assure everyone
2224 the effective freedom to copy and redistribute it, with or without
2225 modifying it, either commercially or noncommercially. Secondarily,
2226 this License preserves for the author and publisher a way to get
2227 credit for their work, while not being considered responsible for
2228 modifications made by others.
2230 This License is a kind of ``copyleft'', which means that derivative
2231 works of the document must themselves be free in the same sense. It
2232 complements the GNU General Public License, which is a copyleft
2233 license designed for free software.
2235 We have designed this License in order to use it for manuals for free
2236 software, because free software needs free documentation: a free
2237 program should come with manuals providing the same freedoms that the
2238 software does. But this License is not limited to software manuals;
2239 it can be used for any textual work, regardless of subject matter or
2240 whether it is published as a printed book. We recommend this License
2241 principally for works whose purpose is instruction or reference.
2245 APPLICABILITY AND DEFINITIONS
2247 This License applies to any manual or other work that contains a
2248 notice placed by the copyright holder saying it can be distributed
2249 under the terms of this License. The ``Document'', below, refers to any
2250 such manual or work. Any member of the public is a licensee, and is
2251 addressed as ``you.''
2253 A ``Modified Version'' of the Document means any work containing the
2254 Document or a portion of it, either copied verbatim, or with
2255 modifications and/or translated into another language.
2257 A ``Secondary Section'' is a named appendix or a front-matter section of
2258 the Document that deals exclusively with the relationship of the
2259 publishers or authors of the Document to the Document's overall subject
2260 (or to related matters) and contains nothing that could fall directly
2261 within that overall subject. (For example, if the Document is in part a
2262 textbook of mathematics, a Secondary Section may not explain any
2263 mathematics.) The relationship could be a matter of historical
2264 connection with the subject or with related matters, or of legal,
2265 commercial, philosophical, ethical or political position regarding
2268 The ``Invariant Sections'' are certain Secondary Sections whose titles
2269 are designated, as being those of Invariant Sections, in the notice
2270 that says that the Document is released under this License.
2272 The ``Cover Texts'' are certain short passages of text that are listed,
2273 as Front-Cover Texts or Back-Cover Texts, in the notice that says that
2274 the Document is released under this License.
2276 A ``Transparent'' copy of the Document means a machine-readable copy,
2277 represented in a format whose specification is available to the
2278 general public, whose contents can be viewed and edited directly and
2279 straightforwardly with generic text editors or (for images composed of
2280 pixels) generic paint programs or (for drawings) some widely available
2281 drawing editor, and that is suitable for input to text formatters or
2282 for automatic translation to a variety of formats suitable for input
2283 to text formatters. A copy made in an otherwise Transparent file
2284 format whose markup has been designed to thwart or discourage
2285 subsequent modification by readers is not Transparent. A copy that is
2286 not ``Transparent'' is called ``Opaque.''
2288 Examples of suitable formats for Transparent copies include plain
2289 ASCII without markup, Texinfo input format, LaTeX input format, SGML
2290 or XML using a publicly available DTD, and standard-conforming simple
2291 HTML designed for human modification. Opaque formats include
2292 PostScript, PDF, proprietary formats that can be read and edited only
2293 by proprietary word processors, SGML or XML for which the DTD and/or
2294 processing tools are not generally available, and the
2295 machine-generated HTML produced by some word processors for output
2298 The ``Title Page'' means, for a printed book, the title page itself,
2299 plus such following pages as are needed to hold, legibly, the material
2300 this License requires to appear in the title page. For works in
2301 formats which do not have any title page as such, ``Title Page'' means
2302 the text near the most prominent appearance of the work's title,
2303 preceding the beginning of the body of the text.
2308 You may copy and distribute the Document in any medium, either
2309 commercially or noncommercially, provided that this License, the
2310 copyright notices, and the license notice saying this License applies
2311 to the Document are reproduced in all copies, and that you add no other
2312 conditions whatsoever to those of this License. You may not use
2313 technical measures to obstruct or control the reading or further
2314 copying of the copies you make or distribute. However, you may accept
2315 compensation in exchange for copies. If you distribute a large enough
2316 number of copies you must also follow the conditions in section 3.
2318 You may also lend copies, under the same conditions stated above, and
2319 you may publicly display copies.
2324 If you publish printed copies of the Document numbering more than 100,
2325 and the Document's license notice requires Cover Texts, you must enclose
2326 the copies in covers that carry, clearly and legibly, all these Cover
2327 Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
2328 the back cover. Both covers must also clearly and legibly identify
2329 you as the publisher of these copies. The front cover must present
2330 the full title with all words of the title equally prominent and
2331 visible. You may add other material on the covers in addition.
2332 Copying with changes limited to the covers, as long as they preserve
2333 the title of the Document and satisfy these conditions, can be treated
2334 as verbatim copying in other respects.
2336 If the required texts for either cover are too voluminous to fit
2337 legibly, you should put the first ones listed (as many as fit
2338 reasonably) on the actual cover, and continue the rest onto adjacent
2341 If you publish or distribute Opaque copies of the Document numbering
2342 more than 100, you must either include a machine-readable Transparent
2343 copy along with each Opaque copy, or state in or with each Opaque copy
2344 a publicly-accessible computer-network location containing a complete
2345 Transparent copy of the Document, free of added material, which the
2346 general network-using public has access to download anonymously at no
2347 charge using public-standard network protocols. If you use the latter
2348 option, you must take reasonably prudent steps, when you begin
2349 distribution of Opaque copies in quantity, to ensure that this
2350 Transparent copy will remain thus accessible at the stated location
2351 until at least one year after the last time you distribute an Opaque
2352 copy (directly or through your agents or retailers) of that edition to
2355 It is requested, but not required, that you contact the authors of the
2356 Document well before redistributing any large number of copies, to give
2357 them a chance to provide you with an updated version of the Document.
2362 You may copy and distribute a Modified Version of the Document under
2363 the conditions of sections 2 and 3 above, provided that you release
2364 the Modified Version under precisely this License, with the Modified
2365 Version filling the role of the Document, thus licensing distribution
2366 and modification of the Modified Version to whoever possesses a copy
2367 of it. In addition, you must do these things in the Modified Version:
2369 A. Use in the Title Page (and on the covers, if any) a title distinct
2370 from that of the Document, and from those of previous versions
2371 (which should, if there were any, be listed in the History section
2372 of the Document). You may use the same title as a previous version
2373 if the original publisher of that version gives permission.@*
2374 B. List on the Title Page, as authors, one or more persons or entities
2375 responsible for authorship of the modifications in the Modified
2376 Version, together with at least five of the principal authors of the
2377 Document (all of its principal authors, if it has less than five).@*
2378 C. State on the Title page the name of the publisher of the
2379 Modified Version, as the publisher.@*
2380 D. Preserve all the copyright notices of the Document.@*
2381 E. Add an appropriate copyright notice for your modifications
2382 adjacent to the other copyright notices.@*
2383 F. Include, immediately after the copyright notices, a license notice
2384 giving the public permission to use the Modified Version under the
2385 terms of this License, in the form shown in the Addendum below.@*
2386 G. Preserve in that license notice the full lists of Invariant Sections
2387 and required Cover Texts given in the Document's license notice.@*
2388 H. Include an unaltered copy of this License.@*
2389 I. Preserve the section entitled ``History'', and its title, and add to
2390 it an item stating at least the title, year, new authors, and
2391 publisher of the Modified Version as given on the Title Page. If
2392 there is no section entitled ``History'' in the Document, create one
2393 stating the title, year, authors, and publisher of the Document as
2394 given on its Title Page, then add an item describing the Modified
2395 Version as stated in the previous sentence.@*
2396 J. Preserve the network location, if any, given in the Document for
2397 public access to a Transparent copy of the Document, and likewise
2398 the network locations given in the Document for previous versions
2399 it was based on. These may be placed in the ``History'' section.
2400 You may omit a network location for a work that was published at
2401 least four years before the Document itself, or if the original
2402 publisher of the version it refers to gives permission.@*
2403 K. In any section entitled ``Acknowledgements'' or ``Dedications'',
2404 preserve the section's title, and preserve in the section all the
2405 substance and tone of each of the contributor acknowledgements
2406 and/or dedications given therein.@*
2407 L. Preserve all the Invariant Sections of the Document,
2408 unaltered in their text and in their titles. Section numbers
2409 or the equivalent are not considered part of the section titles.@*
2410 M. Delete any section entitled ``Endorsements.'' Such a section
2411 may not be included in the Modified Version.@*
2412 N. Do not retitle any existing section as ``Endorsements''
2413 or to conflict in title with any Invariant Section.@*
2415 If the Modified Version includes new front-matter sections or
2416 appendices that qualify as Secondary Sections and contain no material
2417 copied from the Document, you may at your option designate some or all
2418 of these sections as invariant. To do this, add their titles to the
2419 list of Invariant Sections in the Modified Version's license notice.
2420 These titles must be distinct from any other section titles.
2422 You may add a section entitled ``Endorsements'', provided it contains
2423 nothing but endorsements of your Modified Version by various
2424 parties--for example, statements of peer review or that the text has
2425 been approved by an organization as the authoritative definition of a
2428 You may add a passage of up to five words as a Front-Cover Text, and a
2429 passage of up to 25 words as a Back-Cover Text, to the end of the list
2430 of Cover Texts in the Modified Version. Only one passage of
2431 Front-Cover Text and one of Back-Cover Text may be added by (or
2432 through arrangements made by) any one entity. If the Document already
2433 includes a cover text for the same cover, previously added by you or
2434 by arrangement made by the same entity you are acting on behalf of,
2435 you may not add another; but you may replace the old one, on explicit
2436 permission from the previous publisher that added the old one.
2438 The author(s) and publisher(s) of the Document do not by this License
2439 give permission to use their names for publicity for or to assert or
2440 imply endorsement of any Modified Version.
2445 You may combine the Document with other documents released under this
2446 License, under the terms defined in section 4 above for modified
2447 versions, provided that you include in the combination all of the
2448 Invariant Sections of all of the original documents, unmodified, and
2449 list them all as Invariant Sections of your combined work in its
2452 The combined work need only contain one copy of this License, and
2453 multiple identical Invariant Sections may be replaced with a single
2454 copy. If there are multiple Invariant Sections with the same name but
2455 different contents, make the title of each such section unique by
2456 adding at the end of it, in parentheses, the name of the original
2457 author or publisher of that section if known, or else a unique number.
2458 Make the same adjustment to the section titles in the list of
2459 Invariant Sections in the license notice of the combined work.
2461 In the combination, you must combine any sections entitled ``History''
2462 in the various original documents, forming one section entitled
2463 ``History''; likewise combine any sections entitled ``Acknowledgements'',
2464 and any sections entitled ``Dedications.'' You must delete all sections
2465 entitled ``Endorsements.''
2468 COLLECTIONS OF DOCUMENTS
2470 You may make a collection consisting of the Document and other documents
2471 released under this License, and replace the individual copies of this
2472 License in the various documents with a single copy that is included in
2473 the collection, provided that you follow the rules of this License for
2474 verbatim copying of each of the documents in all other respects.
2476 You may extract a single document from such a collection, and distribute
2477 it individually under this License, provided you insert a copy of this
2478 License into the extracted document, and follow this License in all
2479 other respects regarding verbatim copying of that document.
2482 AGGREGATION WITH INDEPENDENT WORKS
2484 A compilation of the Document or its derivatives with other separate
2485 and independent documents or works, in or on a volume of a storage or
2486 distribution medium, does not as a whole count as a Modified Version
2487 of the Document, provided no compilation copyright is claimed for the
2488 compilation. Such a compilation is called an ``aggregate'', and this
2489 License does not apply to the other self-contained works thus compiled
2490 with the Document, on account of their being thus compiled, if they
2491 are not themselves derivative works of the Document.
2493 If the Cover Text requirement of section 3 is applicable to these
2494 copies of the Document, then if the Document is less than one quarter
2495 of the entire aggregate, the Document's Cover Texts may be placed on
2496 covers that surround only the Document within the aggregate.
2497 Otherwise they must appear on covers around the whole aggregate.
2502 Translation is considered a kind of modification, so you may
2503 distribute translations of the Document under the terms of section 4.
2504 Replacing Invariant Sections with translations requires special
2505 permission from their copyright holders, but you may include
2506 translations of some or all Invariant Sections in addition to the
2507 original versions of these Invariant Sections. You may include a
2508 translation of this License provided that you also include the
2509 original English version of this License. In case of a disagreement
2510 between the translation and the original English version of this
2511 License, the original English version will prevail.
2516 You may not copy, modify, sublicense, or distribute the Document except
2517 as expressly provided for under this License. Any other attempt to
2518 copy, modify, sublicense or distribute the Document is void, and will
2519 automatically terminate your rights under this License. However,
2520 parties who have received copies, or rights, from you under this
2521 License will not have their licenses terminated so long as such
2522 parties remain in full compliance.
2525 FUTURE REVISIONS OF THIS LICENSE
2527 The Free Software Foundation may publish new, revised versions
2528 of the GNU Free Documentation License from time to time. Such new
2529 versions will be similar in spirit to the present version, but may
2530 differ in detail to address new problems or concerns. See
2531 http://www.gnu.org/copyleft/.
2533 Each version of the License is given a distinguishing version number.
2534 If the Document specifies that a particular numbered version of this
2535 License ``or any later version'' applies to it, you have the option of
2536 following the terms and conditions either of that specified version or
2537 of any later version that has been published (not as a draft) by the
2538 Free Software Foundation. If the Document does not specify a version
2539 number of this License, you may choose any version ever published (not
2540 as a draft) by the Free Software Foundation.
2544 @unnumberedsec ADDENDUM: How to use this License for your documents
2546 To use this License in a document you have written, include a copy of
2547 the License in the document and put the following copyright and
2548 license notices just after the title page:
2552 Copyright (C) @var{year} @var{your name}.
2553 Permission is granted to copy, distribute and/or modify this document
2554 under the terms of the GNU Free Documentation License, Version 1.1
2555 or any later version published by the Free Software Foundation;
2556 with the Invariant Sections being @var{list their titles}, with the
2557 Front-Cover Texts being @var{list}, and with the Back-Cover Texts being @var{list}.
2558 A copy of the license is included in the section entitled "GNU
2559 Free Documentation License."
2563 If you have no Invariant Sections, write ``with no Invariant Sections''
2564 instead of saying which ones are invariant. If you have no
2565 Front-Cover Texts, write ``no Front-Cover Texts'' instead of
2566 ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts.
2568 If your document contains nontrivial examples of program code, we
2569 recommend releasing these examples in parallel under your choice of
2570 free software license, such as the GNU General Public License,
2571 to permit their use in free software.
2577 -T - "traditional BSD style": How is it different? Should the
2578 differences be documented?
2580 example flat file adds up to 100.01%...
2582 note: time estimates now only go out to one decimal place (0.0), where
2583 they used to extend two (78.67).