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

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

2013/4/3 Andrew Haley <aph@redhat.com>
>
> On 04/03/2013 11:02 AM, Alexander Ivchenko wrote:
>
> > Thank you for your answers, seems that the question about the reason
> > with default -Bsymbolic is still open.. we are not clairvoyant, but it
> > is implemented in GCC so we should understand the reason :)
>
>

Bionic's loader does not support lazy binding nor GNU hash, and
Android's zygote maps about every .so on the system when it boots, so
enabling Bsymbolic saves significant time (the internal relocations
against named symbols are all converted into relative relocations
which only carry a numeric offset, and processing them does not
involve looking up the symbol).

> > Having that in mind, we have:
> > 1) All shared libraries for Android are built with -Bsymbolic
> > 2) Dynamic loader throws an error if we are doing COPY relocation
> > against DT_SYMBOLIC libs.
> >
> > So any COPY relocation is doomed to failure.. Ard, what was the reason
> > for introducing the support of this type of relocations in dynamic
> > loader in the first place?
>

The original implementation allowed them, but was broken. Disallowing
them would break BC, so fixing them was considered the best option.
(I think the initial support predates the default Bsymbolic setting.)

> Well, I could opine that the true breakage is copy relocs, not -Bsymbolic.
> Copy relocs are an ingenious solution to a problem, but they're a kludge.
>

Agreed. Especially on Android, where all static libs are built with
PIC and the default is PIE for executables, copy relocations really
have no place anymore.
(Note that there is a '-z nocopyrelocs' switch on ld which tries to
avoid them, or at least errors out at build time if it fails to)

> -Bsymbolic allows you to do something that's not strictly compatible with
> Standard C/C++, and it's somewhat risky.  However, it's not really a
> terrible idea for shared libraries directly to reference their own data,
> and for executables to reference the data in the shared library.  The
> linker doesn't only link C programs, and not all languages have the one
> definition rule.
>

Note that this preemption not only applies to copy relocations.
Without -Bsymbolic, a shared library will prefer to use a global
defined in your executable over one it defines itself it they happen
to have the same name. This can easily lead to unexpected results.

-- 
Ard.



> One could also argue that -Bsymbolic and PIC can be safer, because it
> doesn't bind the size of a data symbol at compile time.
>
> Andrew.
>