<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/71963>71963</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Assertion failure in RuntimeDyldELF::resolveAArch64Relocation
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          MikaelSmith
      </td>
    </tr>
</table>

<pre>
    Using MCJIT, several projects have run into failures like
```
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:400: void llvm::RuntimeDyldELF::resolveAArch64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion `isInt<33>(Result) && "overflow check failed for relocation"' failed.
```
at https://github.com/llvm/llvm-project/blob/llvmorg-17.0.4/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L518.

* Impala runs into this with LLVM 5.0.1 ([IMPALA-11542](https://issues.apache.org/jira/browse/IMPALA-11542)).
* Numba and Julia have also run into it on newer versions of LLVM (at least 13): https://discourse.llvm.org/t/llvm-rtdyld-aarch64-abi-relocation-restrictions/74616.

I believe this issue is unaddressed in newer releases. As summarized [here](https://discourse.llvm.org/t/llvm-rtdyld-aarch64-abi-relocation-restrictions/74616), MCJIT with the SectionMemoryManager or TrivialMemoryManager allocates sections in separate memory allocation calls. On systems with lots of memory, this can wind up allocating them in different locations in a way that violates AArch64 ABI restrictions (that text and GOT segments must be within 4GB of each other). https://github.com/llvm/llvm-project/commit/574713c3076c11a5677f554ab132d1324be9cb00 is insufficient to fix the issue (tested it in Impala).

RTDyldMemoryManager provides needsToReserveAllocationSpace/reserveAllocationSpace. One proposal is to reserve all necessary memory in a single allocation, ensuring it's one contiguous block. This puts slightly stricter requirements on contiguous memory, which may not be suitable for memory-constrained environments, but for most use-cases it switches from 2-3 allocations to 1 larger allocation. This approach seems to address the issue in Impala.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJysVk1v4zYQ_TX0ZWBBIvVhH3xwPrzIIukW2bTXgqLGFjcU6XIoe91fX5ByEhvIZYsChkxRw-GbeW-GlER6ZxFXrLph1d1MjqF3fvWkXyWa74MO_ax13Wn1B2m7g6fbrw8vjN8C4QG9NLD37geqQNDLA4IfLWgbHGylNqNHAqNfkeV3LF-zOj__0qvRLeOb-5-oxqCdvbc7bZHxzfNogx7w7mS667f7x02m9nsm1mWeM7GGg9MdGHMYmFgzsb42neY8kjMHXK-96uvyGY1TMu7G-EI5S-Fi-XdUE47gT4zXMcZR21CXf4XPxoJP4_fpZYS0JkIf3QCrc00PNjBxKwQT94wvnpFGEy0h-a-Bce4O6LfGHUH1qF5T2rCDrfPgL8Byxpvzt-zTZMoAfQh7iqHwDeObnQ792GbKDYxvUpDT3_zMF-Ob1rj2POv8bl40WZ6VF9b_lR8uHqti8YZzevI1PAx7aWRUCE0SCb0mOOrQw-Pjn09QZXlWAOMLVt08PP2-flzPi6IqOavuGF9cR6eJRqRM7qXqMXN-x_jmh_YyRuXdkSLOKx98yfgy-wDz2zi0EqTt4OtotJzEKw25DwXrAM6CxSN6OKAn7SyB205gGV_IAAYlBSjEmfxrjJ0m5UZPmMWEnkGGNxp86E6mm0uZhDmXrZ5_ED73SMHrpEdifNOUdVFfJfQBWjQaDzhlMeUDNMFoZdd5JMIO9Bt6jxEoUgZrAhqHQXr9D3bAqpsePX6W4P8bfCLgduoeE-ehRziX3BMOzp-epJU79OA8vHh90NJcz0uTdkACmpZFGQHhXnoZEIZk_GYVK1BJYyiDbxboRAGHs9iMC4nHaUFElVKopIWjth2M-3cndhdhDnGfTm-36NEGePOftpdwlCcIvQxw0M4keOdmA-ubB7jMRRRNsgz4MyTtffn2AoS7AW0gGEYK0GICqS2UX24iSpSqBxd69FHAv17kyg2DjoOqKZtCKJE3tSoKWdVNs62qUraF4F0heNniUrV5HlWkLY3brVY6xhubuf6Z-JpkFsNAClFhIeZgKuyL-krP55fYE64p3Ht30B0SWMSOXtwzEvoDrt85-76XKtau__RD5BKjk70jaSLQ4OBsGjkDiwqJpD-9qSExFM8tgxfKiJyjpdFHgmNyGgJnEZSzQe9GNxK0xqnXDF6iMvZjICCjd30wJ5j4TFX196g9TuRFuX2s_pDWsdeqh0GewLrELo06yNZgavGT3TydRF5qix2gPWjvbPIaHbRjmEwdBRgJ5ypWcsw8HXVQPRJsvRuAz8VFhCkzBRjpLypHO3uOSO733kVhEcayCA7OXeOC5Xdis1m3Et1SLOUMV0W9XNaiWYp81q9qKRaiWS5EWVeiXZQLnnf5ctu02CCvOzHTK55zURRFXjRiUeXZQpVtVXXFom3bcis5K3McpDbvXWaWNl81xbIWMyNbNJTuJZxbPE7I4mlY3c38Kim9HXfEytxoCvThJehgcPVxGJ9vIzGoX7klzEZvVr9cctPhFDtfjOLfAAAA___mmiaR">