Re: Prelinking relative relocations in shared objects

[Ian Lance Taylor <ian at airs dot com>]

Jan Vroonhof <jan.vroonhof@insignia.com> writes:

> We have a rather big .so for linux/arm we want to reduce the
> ondisk/flash footprint of. It is currently produced using gcc 2.95.x for various x.
> A substantial part of its on disk size is in the .rel.* sections.
> 
> Presumably this is because we are NOT compiling -fPIC for performance reasons (the difference
> is much higher than I expected for arm).
> 
> However, looking at the contents of the .rel sections, about 50% of
> the relocations are R_ARM_PC24, and a substantial part of those are
> reference to symbols inside the same .so.  So it would seem to me that
> these references could be fixedup at .so creation time (modulo symbol
> lookup rules, but neither -Bdynamic nor linking the objects into one
> object using -r first seems to have any effects).
> 
> Is my reasoning flawed? Is there any way of persuading the toolchain
> to do this automatically?

If I understand you, you are building a shared library, and you are
compiling without -fPIC, and you want to reduce the number of runtime
relocations, and you see a lot of PC relative relocations in your
shared library which refer to symbols defined within your shared
library.  Since they are PC relative, it should be possible to not
generate a PC relative relocation, but simply resolve the relocation.

The relocations probably exist because the ELF linking rules permit
overriding a symbol in a shared library.  Therefore, all references to
global symbols from a shared library require a relocation, whether the
symbol is defined in the same shared library or not.

You can stop this by using -Bsymbolic, which tells the linker that all
references to symbols defined in the same shared library are to be
resolved locally.  If you do want to permit some overriding, you can
use version scripts for fine grained control over particular symbols.

Ian