Re: gprof 2.14 glitches w/ powerpc elf binaries

[Nick Clifton]

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