[llvm-bugs] [Bug 42331] New: [PowerPC64] relocation R_PPC64_REL24 out of range when building LLDB

[via llvm-bugs]

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

            Bug ID: 42331
           Summary: [PowerPC64] relocation R_PPC64_REL24 out of range when
                    building LLDB
           Product: lld
           Version: unspecified
          Hardware: Other
                OS: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: alfredo.junior at eldorado.org.br
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

In a x86_64 host using LLVM 8.0.1 to cross compile FreeBSD to PowerPC64 target,
LLD refuses to link target LLDB with the following error:


ld: error:
/usr/home/alfredo.junior/src/freebsd/contrib/llvm/include/llvm/IR/BasicBlock.h:103:(.text._ZN5clang7CodeGen15CodeGenFunction22EmitNullInitializationENS0_7AddressENS_8QualTypeE+0x54C):
relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431]

This is a very large binary (256 MB) and with recent introduction of
'getThunkSpacing' to allow large binaries to be linked (discussed in
https://bugs.llvm.org/show_bug.cgi?id=40740), I reviewed the code and I think
same logic used for ARM might be necessary to PowerPC64 too. 

I was able to workaround (or fix?) the issue with the following change:

-- a/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
+++ b/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
@@ -764,8 +764,14 @@ uint32_t PPC64::getThunkSectionSpacing() const {
   // See comment in Arch/ARM.cpp for a more detailed explanation of
   // getThunkSectionSpacing(). For PPC64 we pick the constant here based on
   // R_PPC64_REL24, which is used by unconditional branch instructions.
+  //
+  // Reducing it in 0x80000 allow creating 32,768 16 byte Thunks at any
+  // offset in a ThunkSection without risk of a branch to one of the
+  // Thunks going out of range.
+  //
   // 0x2000000 = (1 << 24-1) * 4
-  return 0x2000000;
+  // 0x80000 = 32768 * 16 byte thunk
+  return 0x2000000 - 0x80000;
 }


I also noticed that issue isn't reproduced with LLD from LLVM 9, version 8 is
required. I'm not able to ensure that LLVM9 already has a fix, as it sounds
more like a coincidence due to changes in LLVM9.

-- 
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/20190619/1df3d915/attachment.html>