The first step in generating profile information for your program is to compile and link it with profiling enabled.
To compile a source file for profiling, specify the `-pg' option when you run the compiler. (This is in addition to the options you normally use.)
To link the program for profiling, if you use a compiler such as
to do the linking, simply specify `-pg' in addition to your usual
options. The same option, `-pg', alters either compilation or linking
to do what is necessary for profiling. Here are examples:
cc -g -c myprog.c utils.c -pg cc -o myprog myprog.o utils.o -pg
The `-pg' option also works with a command that both compiles and links:
cc -o myprog myprog.c utils.c -g -pg
Note: The `-pg' option must be part of your compilation options
as well as your link options. If it is not then no call-graph data
will be gathered and when you run
gprof you will get an error
message like this:
gprof: gmon.out file is missing call-graph data
If you add the `-Q' switch to suppress the printing of the call graph data you will still be able to see the time samples:
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
If you run the linker
ld directly instead of through a compiler
cc, you may have to specify a profiling startup file
gcrt0.o as the first input file instead of the usual startup
file crt0.o. In addition, you would probably want to
specify the profiling C library, libc_p.a, by writing
`-lc_p' instead of the usual `-lc'. This is not absolutely
necessary, but doing this gives you number-of-calls information for
standard library functions such as
ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p
If you compile only some of the modules of the program with `-pg', you
can still profile the program, but you won't get complete information about
the modules that were compiled without `-pg'. The only information
you get for the functions in those modules is the total time spent in them;
there is no record of how many times they were called, or from where. This
will not affect the flat profile (except that the
calls field for
the functions will be blank), but will greatly reduce the usefulness of the
If you wish to perform line-by-line profiling, you will also need to specify the `-g' option, instructing the compiler to insert debugging symbols into the program that match program addresses to source code lines. See Line-by-line.
In addition to the `-pg' and `-g' options, older versions of GCC required you to specify the `-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 `-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 `if'
statement, each iteration of each `do' loop, etc. This will
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 `-fprofile-arcs', `-ftest-coverage'
and `-fprofile-values' switches. These switches do not produce
data which is useful to
gprof however, so they are not
discussed further here. There is also the
`-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.