Re: -fPIE and stuff
Kurt Roeckx <kurt <at> roeckx.be> writes:
> On Tue, Feb 14, 2012 at 08:17:09PM +0000, Uoti Urpala wrote:
> > Kurt Roeckx <kurt <at> roeckx.be> writes:
> > > 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.
The DSO the symbol is in is often what matters. And your "even more expensive"
is never true; using protected visibility never makes the already "expensive"
case (indirect load of the address) more expensive.
> 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.
Yes, it fails in that example. But if you're trying to imply that this would
mean protected visibility itself must be wrong, that does not follow: instead,
you can say that the tools were invoked with incorrect arguments (missing
-fPIE).
> > > 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
I meant the kind of text relocations that you can use in libraries on i386 but
not on AMD64, and which -fPIC avoids.
> 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.
How could the linker create different relocations? I think doing that at link
stage would necessarily require adding relocations for the code of the main
executable. Those certainly aren't supported now, and while I haven't checked
the details, I believe adding support would require changing more than the
linker.
As for refusing to create a binary, that would probably be possible at least in
the protected-visibility case, as the protected status is visible in the object
file. OTOH in many cases things could still work, so a warning might be better
than a hard failure (many libraries have no modifiable global variables, and for
many typical uses having parts of the code see different instances of a constant
symbol would still work as long as the contents of the instances are equal).
Reply to: