Re: more __gmon_start__ afflictions

[Philip Blundell <pb@futuretv.com>]

In message <[🔎] 19959f574a%peter@erble.freeserve.co.uk>, 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 
are OK:

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.

p.