[llvm-bugs] [Bug 36779] New: PPC64 large code model .eh_frame uses R_PPC64_REL32 relocations instead of R_PPC64_REL64

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36779

            Bug ID: 36779
           Summary: PPC64 large code model .eh_frame uses R_PPC64_REL32
                    relocations instead of R_PPC64_REL64
           Product: new-bugs
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: obilaniu at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20084
  --> https://bugs.llvm.org/attachment.cgi?id=20084&action=edit
Patch, as a text attachment.

While investigating segfaults in Numba on PPC64LE, which uses JIT to generate
accelerated code, I discovered that while PPC64 text relocations are upgraded
in the large code model, in .eh_frame sections they stay at 32 bits.

This problem is exposed when LLVM is built in Debug mode and then used by Numba
to generate accelerated kernels. LLVM will on occasion place such a large gap
between two sections or modules (>8GB) that 32-bit relocations like
R_PPC64_REL32 cannot reach it, being limited to a displacement of +- 2^31. In
Debug mode this triggers a fatal assert if there are any functions that are not
marked `nounwind` (and thus don't require .eh_frame entries).

The solution that I've found for this problem is directly related to the one
adopted for 6.0.0 regarding x86-64 (https://reviews.llvm.org/D6052):
Conditionally use 8-byte relocations in .eh_frames under the large code-model.
The patch I propose is below.


--- a/lib/MC/MCObjectFileInfo.cpp
+++ b/lib/MC/MCObjectFileInfo.cpp
@@ -289,6 +289,8 @@ void MCObjectFileInfo::initELFMCObjectFileInfo(Triple T) {
   case Triple::mips64el:
     FDECFIEncoding = dwarf::DW_EH_PE_sdata8;
     break;
+  case Triple::ppc64:
+  case Triple::ppc64le:
   case Triple::x86_64:
     FDECFIEncoding = dwarf::DW_EH_PE_pcrel |
                      (Large ? dwarf::DW_EH_PE_sdata8 :
dwarf::DW_EH_PE_sdata4);


At least on the Numba test-suite, this eliminates asserts due to long-ranged
32-bit relocations. Breakpointing llvm::RuntimeDyldELF::resolveRelocation
reveals that indeed, in .eh_frame sections the type-26 (R_PPC64_REL3 2)
relocation have been replaced with the type 44 (R_PPC64_REL64) relocation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180317/0dd7bbed/attachment.html>