This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gprof, ITIMER_PROF


Kris Demuynck wrote:
In the best case, gprof reports the actual timings x10. The reason seems to be that the ITIMER_PROF interval timer is set to 999usec instead of 9999usec.

I don't see how this can be a gcc problem. Gcc has nothing to do with the timer interval used by gprof.


This is perhaps a kernel problem, or perhaps a glibc problem, or perhaps a binutils (gprof) problem. Or this could even perhaps be an inconsistency on your system, if you have replaced one of these things, but not recompiled the others to match.

>The main problem is not the factor 10 (my math is still that >good), but the overflow of the 16 bit counters gprof uses to >derive it statistics.

Again, this isn't a gcc problem, as gcc has nothing to do with the histogram size.

This stems from a limitation of the profil() system call, which requires an unsigned short * parameter. Thus fixing this means a kernel change (and perhaps a new system call to avoid breaking standards conformance), a glibc change, and a binutils change. No gcc changes should be needed. This will probably be difficult to coordinate and accomplish.

Note that the gcc gcov profiler does not have this problem. It is using 64-bit (long long) counters. gcov is implemented entirely within gcc, and as a result we are able to control how it works. This gives you line number counts instead of timings.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]