2013/4/3 Maxim Kuvyrkov <ma...@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.
