Re: gprof & Linux interaction oddity

[Nicholas Miell <nmiell at gmail dot com>]

On Mon, 25 Jul 2005 20:13:16 -0700, Ian Lance Taylor wrote:

> Mike Frysinger <vapier@gentoo.org> writes:
> 
>> > gprof as such doesn't need to know the timing tick.  The profiling
>> > rate is read out of the gmon.out file written by glibc.  glibc appears
>> > to compute the rate like this (sysdeps/unix/sysv/linux/prof-freq.c):
>> 
>> well the issue is the gprof/hertz.c file ... it grabs the hertz value as 
>> reported by glibc via sysconf (which it gets from the kernel) and uses that 
>> to translate ticks to seconds ... so even though glibc writes out the data 
>> correctly, gprof reads it in incorrectly ...
> 
> As far as I know this is not the case.  gprof only uses the hertz()
> function in hertz.c for files which do not start with GMON_MAGIC
> (i.e., "gmon").  The GMON_MAGIC files includes the tick value; older
> formats do not.  But glibc generates GMON_MAGIC files, so for them
> gprof should not need to get the timing tick.  To confirm what I see
> in the sources, I ran strace on gprof, and I did not see it call
> sysconf.
> 
> If you know otherwise, it would help to have more details.
> 
> Ian

It's a glibc bug. Basically, glibc is making assumptions about _SC_CLK_TCK
that do not hold. The only valid use of _SC_CLK_TCK is to determine the
resolution of clock_t.

See the bug in Red Hat's bugzilla for a more detailed discussion.