Re: [PATCH] PR target/65248: [5 Regression] Copy relocation in PIE against protected symbol

[Alan Modra <amodra at gmail dot com>]

On Mon, Mar 02, 2015 at 05:36:24AM -0800, H.J. Lu wrote:
> On Sun, Mar 1, 2015 at 11:48 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> > On Sat, Feb 28, 2015 at 5:42 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> Ue copy relocation in PIE improves performance.  But copy relocation
> >> can't be used to access protected symbols defined in shared libaries
> >> and linker in binutils 2.26 enforces doesn't allow it.  GCC doesn't
> >> know if an external definition is protected or not.  This option adds
> >> -mcopyreloc-in-pie to give user an option to turn it off to avoid problem
> >> at link-time.  OK for trunk?
> >
> > If the option does not work universally for all cases, then the
> > default should be off.
> 
> This optimization isn't the real issue.  The issue here is protected
> symbol in shared library.  It can never be referenced from a normal
> executable and works correctly, as Alan explained.  It doesn't matter
> if this option is off or not since it only applies to PIE.  You can try
> the testcase in PR 65248 without -fPIE -pie.

I see things differently.  We have an old linker hack to avoid dynamic
text relocations in non-PIC executables.  This hack doesn't work
properly with protected visibility variables in shared libraries.
Rather than blaming protected visibility variables, I say the hack is
broken.

Since you rely on the linker hack for your optimization, you've 
extended the problem from non-PIC executables to PIEs..

If you want the optimization enabled by default then it probably would
have been better to do the optimization entirely in the linker,
similar to the way we optimize TLS sequences.  Certainly a switch that
enables the optimization in the compiler is reasonable if that gives
better code, but I can see distros turning it off if you manage to
convince Uros and others that the default should be on.

-- 
Alan Modra
Australia Development Lab, IBM