Re: -fPIE and stuff

[Kurt Roeckx <kurt@roeckx.be>]

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