[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