This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: gprof & Linux interaction oddity
On Monday 25 July 2005 08:27 pm, Ian Lance Taylor wrote:
> Tres Melton <tres@mindspring.com> writes:
> > There is an issue with gprof and getting the current OS' Hz from the
> > elf header in Linux via sysconf(). That value is always set to 100 Hz
> > and it is playing games with profiling code. I have been in contact with
> > a number of the kernel developers and we are preparing to take this
> > issue to the LKML. There is a bug on RedHat's bugzilla regarding this
> > issue and a more detailed report in Gentoo's bugzilla:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=90090
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151763
> >
> > Most of the developers that I have spoken with, including Andrew Morton
> > and John Mylchreest, are in favor of correcting this issue but Linus has
> > previously ruled against it. We are hoping that he will reconsider
> > since the merging of the configurable user hz patch in 2.6.13-rc3.
> >
> > One of the developers, Robert Love, has responded: "Explain why gprof
> > needs to know the _actual_ timing tick." I was hoping that you could
> > help me with that.
>
> 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 ...
glibc reports USER_HZ with sysconf(_SC_CLK_TCK) which the kernel sets
differently from its internal HZ so yes, the gprof values are off
proportionally, where that proportion is HZ / USER_HZ
-mike