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

[Ulrich Weigand]

Hello,

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), 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.)

The patch below attempts to fix 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 the attached 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).

I'd appreciate a review; is this OK to commit?
(See attached file: diff-llvm-dyld-TOC)



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-dyld-TOC
Type: application/octet-stream
Size: 7525 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140620/d70b216c/attachment.obj>