Kurt Roeckx <kurt <at> roeckx.be> writes:
> > What affects the ABI is compiling the library in a way that does not support
> > copy relocations. This can be done with visibility attributes or linker
> It was always my understanding that protected wasn't useful,
> because it's even more expensive.
Sounds like your understanding was wrong. Protected visibility does help library
performance, as it avoids the need to do extra memory loads to resolve symbols.
Protected visibility for everything + fPIE means that each object can address
its own symbols with efficient code (at least on platforms that have efficient
pc-relative addressing). Current "default" means code in the main binary itself
can access everything efficiently, but shared libraries address all global
symbols inefficiently, even their own.
> > Here's an example of a library that requires -fPIE for the main program:
> As far as I understand things, this is supposed to work, and might
It cannot work in the usual setup. Relocations are not supported for the main
binary, even on platforms that support them for shared libraries. This means
that if the code in the main binary has not been compiled with options to make
it position independent, it uses a fixed absolute address for the
end_of_list_sentinel symbol (decided when the binary is linked). On the other
hand, the library accesses its internal symbol with pc-relative addressing. The
load addresses of shared libraries are not fixed at the time the main binary is
linked. Thus we have two addresses: an absolute one, and a relative one that
depends on where in the memory the library is loaded. It's impossible for these
two to reliably match.
Note that the way this works with current "typical" libraries is that the
libraries are compiled with less efficient code that does extra memory loads at
runtime to resolve the address of the symbol, and allows redirecting the symbol
to an arbitrary address. The symbol is then redirected to a copy at an absolute
address that was decided when the main program was linked ("copy relocation").
This way the main program and the library agree on the address. This has the
additional ugliness that things break if the symbol refers to a table and its
size increases in the library after the main program was linked, even if the
library stays ABI compatible at the C level (picking absolute addresses for the
copied symbols at the main program link time depended on knowing their sizes).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120214t202547-...@post.gmane.org
