[Bug binutils/2335] gprof reads executable 10x slower on opteron/x86_64

[dirkjan at magma-da dot com]

------- Additional Comments From dirkjan at magma-da dot com  2006-04-04 07:05 
-------
(In reply to comment #2)
> Can you attach some example binaries, please?  It does not make sense that
> x86-64 binaries produced by a modern version of GCC would produce stabs
> debugging info.  I suspect your debugging session has given you that 
> impression,
> but that it would not be the case.  Thanks.

I have not said 64bit executables produce stabs info. But forcing to do so does
fix slow runtime of gprof on 64bit. 

Using nm or objdump I was seeing a .stabs section on the 32bit which was not
there in the 64bit case. Also as I said the function _bfd_elf_find_nearest_line
in gprof uses _bfd_stabs_find_nearest_line many more times succesfully then
_bfd_dwarf2_find_nearest_line. In case of 64bit it even does fail on that was
and gets into the slow elf_find_function.

Adding -gstabs1 to the 64bit build makes it as fast as 32bit. It seems there is
something related to stabs info being available that makes the difference in
speed of gprof.

So no there is by default NO stabs info in the 64bit exe BUT if it is there
gprof is no longer 10x to 20x slower.

Without stabs info gprof if not efficient (it fails almost always on the
_bfd_dwarf2_find_nearest_line). If gprof would be able to read via
_bfd_dwarf2_find_nearest_line as much as via _bfd_stabs_find_nearest_line then
it might be fast on 64bit without stabs info which is the default.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2335

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.