This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
        


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]