On Tue, Feb 14, 2012 at 08:17:09PM +0000, Uoti Urpala wrote: > 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.
For the DSO the symbol is in yes, but not for other objects that try to use it. Anyway, the C standard says that there is a requirement that both the DSO itself as all other objects must be able to take the address of it and still get the same pointer. And this obviously fails in your example. > > > 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. I'm pretty sure that the main binary supports relocations. Else you wouldn't be complaining about those copy relocations (that can only exist in the executable). However, not all the same types of relocations are supported in executable. And it's not because they're not used that the dynamic linker doesn't support them. > 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). There are at least 2 solutions for this: - Create relocations in the text segment of the executable, and replace all the occurences of variable with the address in the DSO. - Create a duplicate of the symbol in the .bss of the executable and use a copy relocation. You then copy the content of the symbol from the DSO to the executable and make the DSO use the address from the executable by changing it's GOT. The second is what's being used because now the text segment can be read-only. But obviously fails when using a protected symbol since you can't tell the DSO anymore that the symbol is now allocated somewhere else. It's also why -fPIE makes it possible to use the variable from the DSO and why you can avoid this copy relocation. So I would argue that the linker should either have created different relocations or refused to create a binary, since it's creating broken code. Kurt -- 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/20120214222851.ga30...@roeckx.be
