Re: [Android] The reason why -Bsymbolic is turned on by default

[Ard Biesheuvel <ard dot biesheuvel at gmail dot com>]

2013/4/3 Maxim Kuvyrkov <maxim@kugelworks.com>
>
> Now, it appears the problem is that an application cannot use COPY
> relocation to fetch a symbol out of shared -Bsymbolic library.  I don't
> quite understand why this is forbidden by Bionic's linker.  I understand why
> COPY relocations shouldn't be applied to the inside of DT_SYMBOLIC library.
> However, I don't immediately see the problem of applying COPY relocation
> against symbol from DT_SYMBOLIC library to the inside of an executable.
>
> Ard, you committed 5ae44f302b7d1d19f25c4c6f125e32dc369961d9 to Bionic that
> adds handling of ARM COPY relocations.  Can you comment on why COPY
> relocations from executables to DT_SYMBOLIC libraries are forbidden?


Hi all,

The reason that COPY relocations should not be used against shared libraries
built with -Bsymbolic is that *all* references  to the source symbol
(including internal ones and ones from other shared libraries) should be
preempted and made to use the copied version that lives inside the address
range of the executable proper. However, a library built with -Bsymbolic
resolves all its internal references at build time, so any reference held by
the library itself is not preemptible, resulting in two live instances of
the same symbol.

The other way around should not be a problem in the same way, but I don't
think the ELF spec (at least the ARM one) allows it, nor is it very
meaningful (assuming external symbols are referenced through the GOT)

Regards,
Ard.