This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: Support toc relative access to dynamic symbols from static code.


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
for powerpc64.

A better idea is to emit the first sequence you show above, and have
the linker edit to the second when possible.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]