This is the mail archive of the
mailing list for the binutils project.
Re: Patch: Support toc relative access to dynamic symbols from static code.
- From: Alan Modra <amodra at gmail dot com>
- To: Kyle Butt <iteratee at google dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 23 Nov 2015 17:40:37 +1030
- Subject: Re: Patch: Support toc relative access to dynamic symbols from static code.
- Authentication-results: sourceware.org; auth=none
- References: <CABeP02DtWknob5nb8k7x+NVNUnOGpCKPcmA+4HCSkgDhYYR+CA at mail dot gmail dot com> <20151118030750 dot GI8120 at bubble dot grove dot modra dot org> <20151118032851 dot GJ8120 at bubble dot grove dot modra dot org> <CABeP02AVT23VBC1ogwHxTBEUvSUwkauYALejL4fqawDj9dOi6w at mail dot gmail dot com>
On Tue, Nov 17, 2015 at 08:00:11PM -0800, Kyle Butt wrote:
> They don't get emitted as dynamic relocations.
> It does make sense to emit copy relocations for them, and plt entries.
> Consider the two following sequences:
> addis r3, r2, LC0@toc@ha
> ld r3, LC0@toc@l(r3)
> addis r3, r2, sym@toc@ha
> addi r3, r3, sym@toc@l
> At the end of both, r3 contains the value of sym, and so if it is a
> function it needs a plt entry, just as if it was loaded from the toc.
> If the reference is to data, a copy relocation is exactly what is
> needed. A copy relocation would fix the second sequence whenever a
> regular relocation would fix the first.
I see. Defining variables in the executable .dynbss with a copy
relocation for initialisation is an old idea to cope with non-PIC
references to external variables. PowerPC64 shouldn't need to do this
except for initialised pointers in read-only sections since our
compiler output ought to always be PIC. If you make the change to
llvm you're suggesting, there is a problem if the reference is to a
protected visibility variable, which the compiler might not know at
compile time: You'll end up with two copies of the variable, one in
the executable .dynbss and one in the shared library. This can break
program semantics. Now I know that x86_64 gcc and probably x86_64
llvm have cured this with a clever scheme requiring new ld.so handling
of protected visibility variables, but it comes at the cost of
requiring the shared library code to effectively ignore the protected
visibility attribute, instead using code for a pre-emptible normal
visibility variable. That means the shared library code is not as
well optimised. I think this is a mistake, as one of the reasons to
use protected visibility in shared libraries is to enable better
optimisation of the library. Let's not copy the mistakes of x86_64
A better idea is to emit the first sequence you show above, and have
the linker edit to the second when possible.
Australia Development Lab, IBM