Re: Copy relocations against protected symbols

[Alan Modra <amodra at gmail dot com>]

On Sun, Dec 14, 2014 at 04:16:48AM -0800, H.J. Lu wrote:
> On Fri, Dec 12, 2014 at 5:05 AM, Alan Modra <amodra@gmail.com> wrote:
> > Copy relocs are used in a scheme to avoid dynamic text relocations in
> > non-PIC executables that refer to variables defined in shared
> > libraries.  The idea is to have the linker define any such variable in
> > the executable, with a copy reloc copying the initial value, then have
> > both the executable and shared library refer to the executable copy.
> > If the shared library defines the variable as protected then we have
> > two copies of the variable being used.
> 
> This caused:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17709

I think this failure is expected.  What we have here is exactly the
case my linker change is supposed to prevent:  A non-PIC main program
without a definition of a given variable and a shared library with a
protected definition of said variable.  For this we have three choices
as far as I can see:

1) The previous linker behaviour of magically creating a copy of the
variable in .dynbss, that the main program then uses.  This obviously
can change program behaviour compared to a main compiled with -fPIC
(where you shouldn't get the copy).  Incidentally, the vismain/vismod
test in glibc is deficient in not testing behaviour when modifying
protected variables.  If it did, the test would show that the main
variable was in fact *none* of the expected ones.  The test also has a
number of "XXX Possibly enable once fixed" comments.  Well, I've just
fixed them by making the program invalid.  :)

2) As we have now, refusing to link programs that would cause the
linker to create copies of protected variables.  Or a variant, just
warn.

3) Further modify the linker to create dynamic text relocations rather
than a copy reloc.

-- 
Alan Modra
Australia Development Lab, IBM