<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 - RuntimeDyld relocation overflow (Regression in LLVM 12.rc2/trunk)"
href="https://bugs.llvm.org/show_bug.cgi?id=49441">49441</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>RuntimeDyld relocation overflow (Regression in LLVM 12.rc2/trunk)
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Linker
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>wenzel.jakob@epfl.ch
</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=24589" name="attach_24589" title="Reproducer -- crashes with an assertion failure on Trunk">attachment 24589</a> <a href="attachment.cgi?id=24589&action=edit" title="Reproducer -- crashes with an assertion failure on Trunk">[details]</a></span>
Reproducer -- crashes with an assertion failure on Trunk
Dear LLVM team,
I'm using LLVM to JIT-compile relocatable vectorized code across various
platforms.
With the latest LLVM trunk, a large portion of previously working code triggers
an assertion failure while applying relocations in RuntimeDyldCOFFX86_64
(Windows/x64):
Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation overflow", file
C:\\llvm\lib\ExecutionEngine\RuntimeDyld\Targets/RuntimeDyldCOFFX86_64.h, line
105
The same works with LLVM 10 and 11. Something very strange is happening here as
well -- if I enable debug messages, I can see the identifiers of those
relocations, and one seems to have a bogus name, and a very large addend
(4294967295 == -0x1), which is what ultimately triggers the crash.
SectionID: 12
In Section 12 Offset 78 RelType:
4 TargetName: __real@7fffffff Addend 0
In Section 12 Offset 87 RelType: 4 TargetName: __real@3f000000 Addend 0
In Section 12 Offset 96 RelType: 4
TargetName: __real@40490fdb Addend 0
In Section 12 Offset 111 RelType: 4 TargetName: __real@3f800000 Addend 0
In Section 12 Offset 126 RelType: 4
TargetName: __real@3d2cb352 Addend 0
In Section 12 Offset 140 RelType: 4 TargetName: __real@3cc617e3 Addend 0
In Section 12 Offset 149 RelType: 4
TargetName: __real@3d3a3ec7 Addend 0
In Section 12 Offset 158 RelType: 4 TargetName: __real@3d9980f6 Addend 0
In Section 12 Offset 167 RelType: 4
TargetName: __real@3e2aaae4 Addend 0
In Section 12 Offset 176 RelType: 4 TargetName: __real@3fc90fdb Addend 0
In Section 12 Offset 185 RelType: 4
TargetName: __real@80000000 Addend 0
In Section 12 Offset 289 RelType: 4 TargetName:
__ymm@0000000000000000000000000000000000000000000000000000000000000000 Addend
4294967295
I've isolated the smallest piece of code in our test suite that triggers this
crash and wrapped into a tiny MCJIT harness. Please see the attached file.
Best,
Wenzel</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>