On Tue, Apr 26, 2016 at 03:24:48PM +0930, Alan Modra wrote:
> On Mon, Apr 25, 2016 at 11:35:46AM -0600, Jeff Law wrote:
> > No, we revert to the gcc-4.9 behavior WRT protected visibility and ensure
> > that we're getting a proper diagnostic from the linker.
> >
> > That direction is consistent with the intent of protected visibility, fixes
> > the problem with preemption of protected symbols and gives us a diagnostic
> > for the case that can't be reasonably handled.
>
> I agree that this is the correct solution. Unfortunately there is a
> complication. PIE + shared lib using protected visibility worked fine
> with gcc-4.9, but since then code generated by gcc for PIEs on x86_64
> has been optimized to rely on the horrible old hack of .dynbss and
> copy relocations. That means you'll have regressions from 4.9 if just
> reverting the protected visibility change..
>
> The PIE optimization will need reverting too, and I imagine you'll see
> some resistance to that idea due to the fact that it delivers quite a
> nice performance improvement for PIEs.
Yes, that change is IMHO too important to revert, it basically made PIEs
usable without significant slowdown.
Regressing on protected visibility is fine, that is something that is only
rarely used and in an ideal world wouldn't be used at all, because the
current definition really is not an optimization. If we want to use
protected for something, it should be declared that address comparisons are
undefined for them, and for references to protected variables from binaries
(PIEs or normal) or perhaps even other shared libraries (other than the one
with definition) we should just require some extra attribute on them to make
this clear and force using GOT there.
Jakub
