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 09:40:01AM +0100, Richard Biener 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?
> 
> I wonder if the linker can fix this up?  That is, turn the relocation into
> a valid one?

No it can't (*), nor can the dynamic linker.  Copy relocs aren't
really the issue.  They are just a means of initializing a linker
generated variable to be used in place of a variable in a shared
library.  The issue is the linker generated .dynbss variable itself.

Consider an ELF executable linked against a shared library, with the
executable referencing (but not defining) a variable defined in the
shared library.  You'd expect that the executable and shared library
would both use the same location for the variable.  Indeed, that is
true.  Both executable and shared library use the shared library's
variable.  Except there is a wrinkle.  If the executable is non-PIC,
code in the executable will require dynamic text relocations as the
variable's address isn't known until run time.  To avoid that, some
clever person thought: "Why not have the linker define the variable in
the executable?  ELF run time linking semantics mean the shared
library will now use the linker defined copy, so we'll still just be
using one copy of the variable".  Any everyone was happy.  At least
until ELF visibility was invented.

When ELF visibility comes into play, a variable defined in a shared
library with non-default visibility is *not* overridden by another
definition in the executable, be it an actual definition or a linker
generated one.  There is no problem of course if there is an actual
definition in the executable.  In that case the programmer would
expect to see two different variables used.  However, if the shared
library contains a protected visibility variable, and the linker
introduces a copy, then it has changed the meaning of the program.  At
the source level we only had one definition of the variable, but at
run time we'd end up using two different locations.

*) Except by avoiding .dynbss copies and hence requiring dynamic text
relocations.

-- 
Alan Modra
Australia Development Lab, IBM