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

[Hal Finkel]

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> Sent: Friday, June 20, 2014 2:06:46 PM
> Subject: [PATCH, RuntimeDyld] Fix/improve handling of TOC relocations
> 
> 
> 
> 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?

LGTM.

Thanks again,
Hal

> (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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory