OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Minor text corrections

This commit is contained in:
Nick Clifton 2003-10-31 08:59:18 +00:00
parent fc0a224429
commit 83b6e7e845
2 changed files with 41 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
gprof/ChangeLog
View File

@ -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.

36
gprof/gprof.texi
View File

@ -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?