[lld] r250101 - [ELF2] Add a base set of PPC64 relocations

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 13 12:02:44 PDT 2015

> I imagine this is true currently because we create both sections together. Does anything prevent a .got from existing in an input file? When we support the lazy-binding .bss-style .plt sections, we might not have a .got (that's my current understanding).

We would have a .got.plt section. Not sure how that interact with the
ppc64 abi (is it part of the TOC?).

>> Is this here for the same reason as X86_64 and i386? If so, you only
>> need the S.isShared(), no?
> No, I added this specifically because it came up, even in my hello-world test case (because there was some symbol, __gmon_start__ as I recall, that has weak linkage and needs a .plt stub). Maybe I'm just not understanding what is going on, but what would locally resolving such an undefined symbol mean?

But how is a weak undefined making a difference in here? It should
resolve to 0 anyway.

It is also present on x86_64:

$ nm /usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crti.o | grep gmon
                 w __gmon_start__

In any case, even if it is needed for some reason, it is missing a
testcase for that reason. All tests pass if I convert the line to just
"return S.isShared();".

>> git-clang-format.
> No, thank you.

Please do. It is just not worth it having to worry about which parts
are handled by clang-format and which ones are not.

If you particularly dislike the output of clang-format for a
particular code, please open a bug about it.


More information about the llvm-commits mailing list