|
From: | Nick Clifton |
Subject: | Re: gprof 2.14 glitches w/ powerpc elf binaries |
Date: | Tue, 31 Aug 2004 12:46:05 +0100 |
User-agent: | Mozilla Thunderbird 0.7.3 (X11/20040803) |
Hi Nju,
are still listed (even after -D) and we are certain that were never executed. I inserted print statements in my Perl scripts to dump out the address histogram bins as it is about to write them into the gmon.out file and compared them with the address specified in the ELF binary. For instance, in the simple_test.elf that I have attached, the functions _boot0 and _boot were never captured in the trace (they were run, but the trace capture triggered after these functions exited). However, they appear in the profile (simple_test_x86.pro). Even more strange, when we run native gpprof (version 2.10) on the ppc405 processor, these functions are excluded (simple_test.pro). What could be causing this discrepancy?
I am not sure. :-( 2.10 is quite an old version, so possibly there are some bugs in the gprof code that have been fixed in more recent versions and it is these bugs that are preventing your native version from displaying the information about _boot and _boot0. [I am assuming that the native and x86 gprof are being run with essentially the same command line].
Possibly there is a problem with your Perl script and it is adding spurious references to _boot and _boot0 which are then being displayed by the x86 hosted gprof ? (This is just a guess, I am not accusing you or anything).
I logged into a ppc system running Yellow Dog Linux and ran its gprof (v 2.13) and it showed the _boot and _boot0 entries (in the simple_test_sol.out file), and I built a cross-hosted version running on an x86 host, targeted at the powerpc (v2.15.90) and this also showed them. So as far as I can tell these entries really do exist.
Cheers Nick
[Prev in Thread] | Current Thread | [Next in Thread] |