[RuntimeDyld, PowerPC] Fix/improve handling of TOC relocations

Current PPC64 RuntimeDyld code to handle TOC relocations has two
problems:

- With recent linkers, in addition to the relocations that implicitly
  refer to the TOC base (R_PPC64_TOC*), you can now also use the .TOC.
  magic symbol with any other relocation to refer to the TOC base
  explicitly.  This isn't currently used much in ELFv1 code (although
  it could be), but it is essential in ELFv2 code.

- In a complex JIT environment with multiple modules, each module may
  have its own .toc section, and TOC relocations in one module must
  refer to *its own* TOC section.  The current findPPC64TOC implementation
  does not correctly implement this; in fact, it will always return the
  address of the first TOC section it finds anywhere.  (Note that at the
  time findPPC64TOC is called, we don't even *know* which module the
  relocation originally resided in, so it is not even possible to fix
  this routine as-is.)

This commit fixes both problems by handling TOC relocations earlier, in
processRelocationRef.  To do this, I've removed the findPPC64TOC routine
and replaced it by a new routine findPPC64TOCSection, which works
analogously to findOPDEntrySection in scanning the sections of the
ObjImage provided by its caller, processRelocationRef.  This solves the
issue of finding the correct TOC section associated with the current
module.

This makes it straightforward to implement both R_PPC64_TOC relocations,
and relocations explicitly refering to the .TOC. symbol, directly in
processRelocationRef.  There is now a new problem in implementing the
R_PPC64_TOC16* relocations, because those can now in theory involve
*three* different sections: the relocation may be applied in section A,
refer explicitly to a symbol in section B, and refer implicitly to the
TOC section C.  The final processing of the relocation thus may only
happen after all three of these sections have been assigned final
addresses.  There is currently no obvious means to implement this in
its general form with the common-code RuntimeDyld infrastructure.

Fortunately, ppc64 code usually makes no use of this most general form;
in fact, TOC16 relocations are only ever generated by LLVM for symbols
residing themselves in the TOC, which means "section B" == "section C"
in the above terminology.  This special case can easily be handled with
the current infrastructure, and that is what this patch does.
[ Unhandled cases result in an explicit error, unlike the current code
which silently returns the wrong TOC base address ... ]

This patch makes the JIT work on both BE and LE (ELFv2 requires
additional patches, of course), and allowed me to successfully run
complex JIT scenarios (via mesa/llvmpipe).

Reviewed by Hal Finkel.

llvm-svn: 211885

1 files changed, 2 insertions, 1 deletions

diff --git a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h
index b84883310b4..59fdfbe3252 100644
--- a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h
+++ b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h
@@ -82,7 +82,8 @@ class RuntimeDyldELF : public RuntimeDyldImpl {
       return 1;
   }
 
-  uint64_t findPPC64TOC() const;
+  void findPPC64TOCSection(ObjectImage &Obj, ObjSectionToIDMap &LocalSections,
+                           RelocationValueRef &Rel);
   void findOPDEntrySection(ObjectImage &Obj, ObjSectionToIDMap &LocalSections,
                            RelocationValueRef &Rel);