Re: -fPIE and stuff

[Kurt Roeckx <kurt@roeckx.be>]

On Wed, Feb 15, 2012 at 12:09:41AM +0000, Uoti Urpala wrote:
> > 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).

Or that the tools don't implement the needed things to make it
work without -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.

Which has nothing to do with the executable?

> > 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.

And nobody will be interested in implementing it either.

> 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).

I really see no point in exporting constants and then marking
them protected.  About the only useful exported constant I
can think of is something like a version string.  And you
really want to use a function for that.

For all other cases I can't see how it's supposed to work.


Kurt