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]

Re: Update gprof documentation


Hi Guys.

  Ok - how about this additional text to clear up the description
  about gcc command line options ?

Cheers
        Nick
        
2003-10-30  Nick Clifton  <nickc@redhat.com>

	* gprof.texi (Compiling): Describe how to use gprof when source
	files are not compiled with -pg.  Mention other profiling options
	supported by gcc.
	(How do I?): Mention the function call overhead introduced by -pg.

Index: gprof/gprof.texi
===================================================================
RCS file: /cvs/src/src/gprof/gprof.texi,v
retrieving revision 1.11
diff -c -3 -p -r1.11 gprof.texi
*** gprof/gprof.texi	29 Oct 2003 18:21:10 -0000	1.11
--- gprof/gprof.texi	30 Oct 2003 10:44:38 -0000
*************** cc -o myprog myprog.c utils.c -g -pg
*** 280,292 ****
  @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
--- 280,309 ----
  @end example
  
  Note: The @samp{-pg} option must be part of your compilation options
! as well as your link options.  If it is not then only limited
! profiling information will be gathered and when you run @code{gprof}
! you will get error message like this:
  
  @example
  gprof: gmon.out file is missing call-graph data
  @end example
  
+ If you add the @samp{-Q} switch to suppress the printing of the call
+ graph data you will still be able to see some time samples:
+ 
+ @example
+ Flat profile:
+ 
+ Each sample counts as 0.01 seconds.
+   %   cumulative   self              self     total           
+  time   seconds   seconds    calls  Ts/call  Ts/call  name    
+  44.12      0.07     0.07                             zazLoop
+  35.29      0.14     0.06                             main
+  20.59      0.17     0.04                             bazMillion
+ 
+  %         the percentage of the total running time of the
+ @end example
+ 
  If you run the linker @code{ld} directly instead of through a compiler
  such as @code{cc}, you may have to specify a profiling startup file
  @file{gcrt0.o} as the first input file instead of the usual startup
*************** statement, each iteration of each @samp{
*** 328,333 ****
--- 345,360 ----
  enable @code{gprof} to construct an annotated source code
  listing showing how many times each line of code was executed.
  
+ It also worth noting that GCC supports a different profiling method
+ which is enabled by the @samp{-fprofile-arcs}, @samp{-ftest-coverage}
+ and @samp{-fprofile-values} switches. These switches do not produce
+ data which is useful to @code{gprof} however, so they are not
+ discussed further here.  There is also the
+ @samp{-finstrument-functions} switch which will cause GCC to insert
+ calls to special user supplied instrumentation routines at the entry
+ and exit of every function in their program.  This can be used to
+ implement an alternative profiling scheme.
+ 
  @node Executing
  @chapter Executing the Program
  
*************** Looking at the per-line call counts only
*** 1645,1651 ****
  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?
  
--- 1672,1681 ----
  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.  Beware however that this can introduce
! artifical hot spots since compiling with @samp{-pg} adds a significant
! overhead to function calls.  An alternative solution is to use a
! non-intrusive profiler, eg oprofile.
  
  @item How do I find which lines in my program were executed the most times?
  


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