This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Copy relocations against protected symbols
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 15 Dec 2014 11:37:49 +1030
- Subject: Re: Copy relocations against protected symbols
- Authentication-results: sourceware.org; auth=none
- References: <20141212130509 dot GB23430 at bubble dot grove dot modra dot org> <CAMe9rOqmG2Qbn56kbndm3mZq5c5-fjdJs2mQNXj4GvzRTk3Ahw at mail dot 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