Re: more __gmon_start__ afflictions
In message <email@example.com>, Peter Naulls writes:
>Is there any identifier I can look for to check for any other broken
>binaries on my system, with the misbehaving binutils?
If "objdump -R" reveals that the only reloc involving __gmon_start__ is an
R_ARM_GLOB_DAT, you are OK. If there is an R_ARM_JUMP_SLOT reloc, you need to
use "objdump --dynamic-syms"; if there is a weak definition, like this, you
02056438 w DF .text 00000000 Base __gmon_start__
but if there is a weak undefined reference, you may be in trouble:
020019d0 w DF *UND* 00000000 __gmon_start__
Not all binaries with this problem will crash today. The bug actually
occurs if a binary was compiled under glibc 2.2 and uses shared libraries that
were compiled under glibc 2.1 - when those libraries are themselves recompiled
against glibc 2.2, the binary will start to crash.