This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Update gprof documentation
- From: Nick Clifton <nickc at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 29 Oct 2003 18:12:03 +0000
- Subject: Update gprof documentation
Hi Guys,
At the request of RMS I am applying this patch to the gprof
documentation.
Cheers
Nick
2003-10-29 Nick Clifton <nickc@redhat.com>
* gprof.texi: Apply patch supplied by Eric S Raymond via RMS.
(Compiling): Mention that -pg must be passed to both the compiler
and the linker.
Mention that -a is now deprecated.
(How do I?): Add an entry describing how to get more information
about program hotspots.
Index: gprof/gprof.texi
===================================================================
RCS file: /cvs/src/src/gprof/gprof.texi,v
retrieving revision 1.10
diff -c -3 -p -r1.10 gprof.texi
*** gprof/gprof.texi 30 Jul 2002 07:02:54 -0000 1.10
--- gprof/gprof.texi 29 Oct 2003 18:19:35 -0000
*************** This manual describes the @sc{gnu} profi
*** 53,61 ****
can use it to determine which parts of a program are taking most of the
execution time. We assume that you know how to write, compile, and
execute programs. @sc{gnu} @code{gprof} was written by Jay Fenlason.
@vskip 0pt plus 1filll
! Copyright @copyright{} 1988, 92, 97, 98, 99, 2000 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
--- 53,62 ----
can use it to determine which parts of a program are taking most of the
execution time. We assume that you know how to write, compile, and
execute programs. @sc{gnu} @code{gprof} was written by Jay Fenlason.
+ Eric S. Raymond made some minor corrections and additions in 2003.
@vskip 0pt plus 1filll
! Copyright @copyright{} 1988, 92, 97, 98, 99, 2000, 2003 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
*************** The @samp{-pg} option also works with a
*** 278,283 ****
--- 279,292 ----
cc -o myprog myprog.c utils.c -g -pg
@end example
+ Note: The @samp{-pg} option must be part of your compilation options
+ as well as your link options. If it is not, when you run @code{gprof}
+ you will get no profile report and an error message like this:
+
+ @example
+ gprof: gmon.out file is missing call-graph data
+ @end example
+
If you run the linker @code{ld} directly instead of through a compiler
such as @code{cc}, you may have to specify a profiling startup file
@file{gcrt0.o} as the first input file instead of the usual startup
*************** instructing the compiler to insert debug
*** 307,316 ****
that match program addresses to source code lines.
@xref{Line-by-line}.
! In addition to the @samp{-pg} and @samp{-g} options,
! you may also wish to specify the @samp{-a} option when compiling.
! This will instrument
! the program to perform basic-block counting. As the program runs,
it will count how many times it executed each branch of each @samp{if}
statement, each iteration of each @samp{do} loop, etc. This will
enable @code{gprof} to construct an annotated source code
--- 316,328 ----
that match program addresses to source code lines.
@xref{Line-by-line}.
! In addition to the @samp{-pg} and @samp{-g} options, older versions of
! GCC required you to specify the @samp{-a} option when compiling in
! order to instrument it to perform basic-block counting. Newer
! versions do not require this option and will not accept it;
! basic-block counting is always enabled when @samp{-pg} is on.
!
! When basic-block counting is enabled, as the program runs
it will count how many times it executed each branch of each @samp{if}
statement, each iteration of each @samp{do} loop, etc. This will
enable @code{gprof} to construct an annotated source code
*************** nonce, the estimated figures are usually
*** 1627,1632 ****
--- 1639,1652 ----
@chapter Answers to Common Questions
@table @asis
+ @item How can I get more exact information about hot spots in my program?
+
+ Looking at the per-line call counts only tells part of the story.
+ Because @code{gprof} can only report call times and counts by function,
+ the best way to get finer-grained information on where the program
+ is spending its time is to re-factor large functions into sequences
+ of calls to smaller ones.
+
@item How do I find which lines in my program were executed the most times?
Compile your program with basic-block counting enabled, run it, then