[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
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
> 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