<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - PPC64 large code model .eh_frame uses R_PPC64_REL32 relocations instead of R_PPC64_REL64"
href="https://bugs.llvm.org/show_bug.cgi?id=36779">36779</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>PPC64 large code model .eh_frame uses R_PPC64_REL32 relocations instead of R_PPC64_REL64
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>obilaniu@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=20084" name="attach_20084" title="Patch, as a text attachment.">attachment 20084</a> <a href="attachment.cgi?id=20084&action=edit" title="Patch, as a text attachment.">[details]</a></span>
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 (<a href="https://reviews.llvm.org/D6052">https://reviews.llvm.org/D6052</a>):
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>