n_hist_scale does not attempt to become an integral value

Brian Grayson bgrayson.opensource@gmail.com
Tue Aug 31 14:49:41 GMT 2021


It's been quite some time since I've dabbled with the internals of gprof,
but when I print out the value of n_hist_scale, it appears it is not
attempting to ensure it is an integral value. gmon.c says (
https://code.woboq.org/userspace/glibc/gmon/gmon.c.html#129):

round lowpc and highpc to multiples of the density we're using
so the rest of the scaling (here and in gprof) stays in ints.

If I make a pretty small executable with the -pg flag and parse the
resulting gmon.out file, I see:

low_pc is 0x4004d0, hi_pc is 0x4006d8 (distance covered is 520 bytes),
hist_size is 132, and there are 3.9393939393939394 bytes covered per bin
n_hist_scale would be 1.9696969696969697

Is there a reason we don't say n_hist_scale = *round*(<n_hist_scale
expression>)? This can end up causing incorrect information in the profile
output, especially for functions near highpc that are actually unused but
the inaccurate fraction and the overlap computation makes them appear to be
used, or vice versa.

>From experimenting, it does not appear to always be a matter of adding +4
to the n_hist_scale expression -- the example above requires +8 to get
integral values.

Thanks.

Brian Grayson


More information about the Binutils mailing list