I have recently encountered a gross inaccuracy in gprof that
I can't explain. Yes, I know gprof uses a sampling technique
so I should not expect a high level of precision, but the results
I am getting clearly reflect a more fundamental issue.
The program in question has been compiled with -pg for
rong with either gprof or the way
I am using it.
Jon
-Original Message- From: gcc-ow...@gcc.gnu.org
[mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jon Turner Sent: Sunday,
February 21, 2010 7:27 PM To: gcc@gcc.gnu.org Subject: Gprof can
account for less than 1/3 of execution ti
Yes, it is statically linked. In any case, there is very
little usage of external libraries here.
Jon
Alan Modra wrote:
On Sun, Feb 21, 2010 at 12:27:04PM -0600, Jon Turner wrote:
The program in question has been compiled with -pg for all
source code files.
Linked statically too? If not
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 :
Hi,
On Sun, 21 Feb 2010, Jon Turner wrote:
I have recently encountered a gross inaccuracy in gprof that
I can't
Ok, this is not as simple as I would like to make it,
but hopefully it's simple enough. I've placed a tar file at
www.arl.wustl.edu/~jst/gprof-tarfile
In it, you will find a directory with all the source code
needed to observe the problem for yourself.
The top level directory contains a linux ex
Doh! Thanks, Nathan. I think you put your finger on it.
I was well aware of the overhead that gprof can introduce,
but did not recognize that this overhead was not being
counted by gprof.
Jon
Nathan Froyd wrote:
On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote:
In it, you will find
