This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: gprof question
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Dave Cottingham <dcottingham00 at comcast dot net>
- Cc: binutils at sources dot redhat dot com
- Date: 05 Apr 2004 13:50:06 -0400
- Subject: Re: gprof question
- References: <1080489269.11227.641.camel@dcottingham.erols.com><1E08D5F4-8158-11D8-BC8C-000A95A4DC02@kernel.crashing.org><1080701576.1344.22.camel@dcottingham.erols.com><1081136036.1573.49.camel@dcottingham.erols.com>
Dave Cottingham <dcottingham00@comcast.net> writes:
> In case anyone was wondering, I have figured out what causes gprof to
> report a total cumulative time substantially shorter than the actual
> total CPU time. The histogram counters are unsigned shorts, so if you
> get more than 2^16 hits in one or more counters, they wrap, and hence
> the total cumulative time reported by gprof comes up short.
This is an ironic place where this historical kernel system call can
come up short compared to an unconstrained implementation. In
simulators (e.g. sid) it is not a problem to widen the counters.
Because the gmon.out format permits this, they can write out as many
consecutive histogram tables as needed to represent larger values.
gprof itself can correctly digest larger values when stored this way.
- FChE