After PrePrunePass `claimOrExternalizeWeakAndCommonSymbols`, a defined symbol might become external. So determine a function call is external or not when building the linkgraph is not accurate. This largely affects updating TOC pointer on PowerPC. TOC pointer is supposed to be the same in one object file(if no mulitple TOC appears) and is updated when control flow transferred to another object file.
This patch defers checking a function call is external or not, in `buildTables_ELF_ppc64` which is a PostPrunePass.
This patch fixes failures when `jitlink -orc-runtime=/path/to/libort_rt.a` is used.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155925
According to the ELFv2 ABI
> This relocation type is used to specify a function call where the TOC pointer is not initialized. It is similar to R_PPC64_REL24 in that it specifies a symbol to be resolved. If the symbol resolves to a function that requires a TOC pointer (as determined by st_other bits) then a link editor must arrange for the call to be via the global entry point of the called function. Any stub code must not rely on a valid TOC base address in r2.
This patch fixes handling of `R_PPC64_REL24_NOTOC` by using the same stub code sequence as lld.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155672
This patch introduces a skeleton JITLink ppc64 support header and ELF/ppc64
backend. No relocations are supported in this initial version, but given a
program requiring no relocations (e.g. one that just returns a constant value
from main) the new backend is able to construct a LinkGraph from a ppc64 ELF
relocatable object, and the llvm-jitlink tool is able to execute it.
This commit should also serve as a good example of how to introduce a JITLink
backend for a new architecture.
Reviewed By: sgraenitz, v.g.vassilev, vchuravy, nemanjai, jain98, MaskRay
Differential Revision: https://reviews.llvm.org/D148192
