[lld] r250101 - [ELF2] Add a base set of PPC64 relocations
Rafael EspĂndola via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 14 07:37:52 PDT 2015
>> It is missing a test case, but this brings up a question: Why does the x86 logic do the right thing? It seems that lld resolves the weak symbol reference to 0 during linking, but is that right? Can't it still be provided by an LD_PRELOAD? When I link a program with ld.bfd on PPC64, it leaves a dynamic binding and stub to __gmon_start__ in the final executable.
>
> My understanding is that resolving to 0 was the correct behaviour.
> Weak symbols don't even fetch archive members, it seems strange that
> they still show up in the dynamic reloc. I will run some tests,
> thanks.
It looks like gold and bfd have a funny logic as to when a weak
undefined shows up in dynamic revocations.
Given
.globl _start
_start:
.weak sym1
.long sym1 at gotpcrel
.weak sym2
.long sym2 at plt
.weak sym3
.quad sym3
There will be relocs for sym1 and sym2, but I cannot understand the
logic. If the dynamic linker must get a chance to look for sym1 and
sym2, it must also get one for sym3.
Cheers,
Rafael
More information about the llvm-commits
mailing list