<html>
<head>
<base href="http://llvm.org/bugs/" />
</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 --- - RuntimeDyldELF doesn't handle >2GB relocations on x86-64 platforms"
href="http://llvm.org/bugs/show_bug.cgi?id=15356">15356</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>RuntimeDyldELF doesn't handle >2GB relocations on x86-64 platforms
</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>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Generic Execution Engine Support
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrew.kaylor@intel.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>On x86-64 platforms, RuntimeDyldELF cannot be guaranteed to handle 32-bit
relative relocations correctly. Although the SectionMemoryManager attempts to
allocate all loaded sections in proximity to one another, this cannot be
guaranteed. Furthermore, RuntimeDyldELF should not be dependent upon the
memory manager's allocation scheme to perform correctly.
The specific relocation in question is R_X86_64_PC32, which is typically used
with a call or jump instruction. It may be possible to solve this problem by
generating a stub within the source section that can bridge the gap to the
target section. However, some investigation is necessary to verify that this
approach will work in all cases.
Note that the assertion in the RuntimeDyldELF handler for the R_X86_64_32 and
R_X86_64_32S relocation types covers a different situation. If that assertion
fires, it is almost certainly because code was generated with the small memory
model and is being loaded above the 2GB boundary. When the small memory model
is used on x86-64 (not recommended), it is the responsible of the client code
to provide a memory manager which guarantees that code will be loaded below the
2GB boundary.</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>