Patch: Support toc relative access to dynamic symbols from static code.
Wed Nov 18 04:00:00 GMT 2015
On Tue, Nov 17, 2015 at 7:28 PM, Alan Modra <email@example.com> wrote:
> On Wed, Nov 18, 2015 at 01:37:50PM +1030, Alan Modra wrote:
>> On Tue, Nov 17, 2015 at 04:52:41PM -0800, Kyle Butt wrote:
>> > This patch allows TOC16_* relocations to reference external global
>> > symbols. Previously llvm was not emitting such accesses, but they are
>> > allowed by the abi.
>> Huh? The patch does nothing, besides making the source ugly.
> I take that back. I'm not used to seeing switch statements without
Sorry about that. I've attached an updated patch.
>However, I still don't like the idea of emitting dynamic
> R_PPC64_TOC16* relocs, if that is what you're trying to do. That
> doesn't make sense at all since those relocs are not handled by
> glibc's ld.so. It also doesn't make sense to emit plt entries or copy
> relocs for them.
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.
> Alan Modra
> Australia Development Lab, IBM
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1621 bytes
Desc: not available
More information about the Binutils