Re: -pg option

[Will Cohen <wcohen at redhat dot com>]

gprof will have difficulty profiling gcc. gprof is designed to collect 
data on a simple single threaded program. When gcc is being built a 
number of different executables are run (gcc, cc1, cc1plus, etc.). 
Unfortunately, each executable is going to try to dump the profiling 
data into a file call gmon.out. Different executables are going to 
overwrite the gmon.out file, so the data isn't going to stay around.

You can get flat profile information from oprofile (or oprofile with 
prospect). oprofile doesn't collect call graph information.

You might use the test coverage information(-fprofile-arcs and 
-ftest-coverage) to get an indication how often section of code are 
executed:

http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Debugging-Options.html#Debugging%20Options

There is one caution with the -fprofile-arcs information. The counters 
are 32-bits in size, it is possible for them to roll over on a task the 
size of bootstrapping gcc.

-Will Cohen

Reza Roboubi wrote:
> In my previous message I asked:
>
> What is the right way to turn on the -pg option when we are compiling
> gcc 3.x?
> (So that we can profile the resulting executables with gprof)
>
>
> Since nobody has responded, should I assume there is no "standard" way
> to do it?
>
> I'd really appreciate even any good hints you can provide.  Right now
> I'm just trying to understand the code better to  possibly make changes
> to it later.
>
> Thank you.