Hi Jon, What does ldd says about your executable?
Thanks ++Cyrille -----Original Message----- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jon Turner Sent: Monday, February 22, 2010 3:44 PM To: Joern Rennecke Cc: Michael Matz; gcc@gcc.gnu.org Subject: Re: Gprof can account for less than 1/3 of execution time?!?! You're not listening. I am using -pg and the program is statically linked. The concern I am raising is not about the function counting, but the reported running times, which are determined by sampling (read the gprof manual, if this is news to you). In this case, the mcount overhead cannot account for the discrepancy, since that would cause gprof to OVER-estimate the run time, while in this case it is UNDER-estimating. It's missing about 70% of the actual running time in the program. It conceivably I am doing something wrong. I hope so, since once I know what it is, I can fix it. But at the moment, it's hard to avoid the suspicion that something about the gprof implementation is deeply flawed. Jon Joern Rennecke wrote: > Quoting Michael Matz <m...@suse.de>: > >> Hi, >> >> On Sun, 21 Feb 2010, Jon Turner wrote: >> >>> I have recently encountered a gross inaccuracy in gprof that >>> I can't explain. Yes, I know gprof uses a sampling technique >> >> This is incorrect. Code compiled with -pg will call mcount on each >> function entry. If there are many calls (compared to other computations) >> the mcount overhead might become fairly large. > > The mcount overhead actually depends on the machine description, although > most ports have standardized on a very runtime profligate scheme.