[Bug gprof/2776] Strange profiling results

[dmantipov at yandex dot ru]

------- Additional Comments From dmantipov at yandex dot ru  2006-06-22 14:55 
-------
(In reply to comment #1)

> Have you checked the assembler output of the compiler ?  Perhaps it is 
> being clever.  Maybe it knows that all but the calls to gettimeofday are 
> redundant ?

Strace shows a lot of gettimeofday() calls during execution of the first test
program above.

Moreover, I've checked an annotated assemler output produced with
'-fverbose-asm' by gcc 4.0.2 and  gcc 4.1.1 and found that even with '-O3', the
code is assembled 'as is', i.e.
at least:
 - rdtsc and gettimeofday() aren't eliminated
 - loops aren't unrolled

> What about main(), is any time spent in that function ?

Flat profile doesn't include  data for main(), i.e. it  contains f() and g()
only. But the call graph shows something for main() too, for example:

index % time    self  children    called     name
                                                 <spontaneous>
[1]    100.0    0.00    0.50                 main [1]
                0.49    0.00     100/100         f [2]
                0.01    0.00     100/100         g [3]
-----------------------------------------------
                0.49    0.00     100/100         main [1]
[2]     98.0    0.49    0.00     100         f [2]
-----------------------------------------------
                0.01    0.00     100/100         main [1]
[3]      2.0    0.01    0.00     100         g [3]
 
Assembler output says that mcount() is called from main(), so main() should be
accounted too. On the other side, it's possible that main() is just too fast
even for 1 profiling sample (all SIGPROFs was handled when we're in f() or g()
?). I believe this is another question for you - why main() isn't included into
flat profile :-) ?
 
> Also it appears that the two percentages above add up to more than 100%.

Yes, this is strange. 
 
> The most likely though is that bad profiling data is being generated. 
> ie it is not gprof's fault but either gcc's (for not inserting the calls 
> to the profiling hooks correctly) or else the run time C library's (for 
> not implementing the profiling hooks correctly).  Check you version of 
> gcc.  If it is an old one, then try updating it.  If it is a new one, 
> then try using an older one and see if the problem goes away.

I'll try a few versions of older gcc, starting from gcc 3.2...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2776

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.