summaryrefslogtreecommitdiff
path: root/gprof
diff options
context:
space:
mode:
authorNick Clifton <nickc@redhat.com>2003-10-31 08:59:18 +0000
committerNick Clifton <nickc@redhat.com>2003-10-31 08:59:18 +0000
commit83b6e7e8457133ccde176aebc88a4d2f7f8ba12e (patch)
tree169cad38afe61cb94d22dfab5b3a026de3cf97c2 /gprof
parentfc0a224429224e8ce0c1adb631e10124a597cc6d (diff)
downloadbinutils-gdb-83b6e7e8457133ccde176aebc88a4d2f7f8ba12e.tar.gz
Minor text corrections
Diffstat (limited to 'gprof')
-rw-r--r--gprof/ChangeLog9
-rw-r--r--gprof/gprof.texi36
2 files changed, 41 insertions, 4 deletions
diff --git a/gprof/ChangeLog b/gprof/ChangeLog
index ead02264337..7014bb08b70 100644
--- a/gprof/ChangeLog
+++ b/gprof/ChangeLog
@@ -1,6 +1,13 @@
+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.
+
2003-10-29 Nick Clifton <nickc@redhat.com>
- * gprof.texi: Apply patch supplied by Eric S Raymond via RMS.
+ * 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.
diff --git a/gprof/gprof.texi b/gprof/gprof.texi
index 3413d996ec1..8c240b138fa 100644
--- a/gprof/gprof.texi
+++ b/gprof/gprof.texi
@@ -280,13 +280,30 @@ 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:
+as well as your link options. If it is not then no call-graph data
+will be gathered and when you run @code{gprof} you will get an 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 the 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
@@ -328,6 +345,16 @@ statement, each iteration of each @samp{do} loop, etc. This will
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
@@ -1645,7 +1672,10 @@ 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.
+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, e.g.@: oprofile.
@item How do I find which lines in my program were executed the most times?