| Issue |
174305
|
| Summary |
LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager() still not usable for Aarch64
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
macdice
|
While adjusting PostgreSQL for LLVM 22, I was happy to see that [commit 2222cfe7](https://github.com/llvm/llvm-project/commit/2222cfe7e11ff3e0434bc696856629199ef0da7c) has partially fixed SectionMemoryManager for Aarch64 systems. Like several other projects, we've been carrying our [own copy](https://github.com/postgres/postgres/blob/master/src/backend/jit/llvm/SectionMemoryManager.cpp) of the patched class from https://github.com/llvm/llvm-project/pull/71968 and we'll continue to use that for `LLVM_VERSION_MAJOR < 22` until the relevant versions drop off our support list in a few years.
I see that `LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager()` will still use the default arguments to `SectionMemoryManager`'s constructor, namely `ReserveAlloc = false`, which means that a program using that function still has no way to JIT code on Aarch64 without crashing on large memory systems. My (probably naive) question is: does LLVM know somewhere that Aarch64 has this relocation limitation, and why shouldn't it be true, at the very least when it is *needed* to work? Otherwise what is the point of the function, given you can't really use it in portable programs?
This isn't a show-stopper for us, we'll just have to keep knowledge of this Aarch64 peculiarity and continue to maintain [extra C++ code](https://github.com/postgres/postgres/blob/master/src/backend/jit/llvm/llvmjit_wrap.cpp) that can construct the object we need just to set it to true. It will of course be a nice improvement not to have to use our own copy of SectionMemoryManager for `LLVM_VERSION_MAJOR >= 22`, but it occurred to me to ask if this isn't really an oversight/bug.
(I know we should use JITLink instead and forget about RuntimeDyld, we're [working on that](https://github.com/macdice/postgres/commit/cac92d0786db7686cf449ff1535d8da558eec206) and https://github.com/llvm/llvm-project/pull/169862 was one step but we still need to figure out how to get GDB and Perf integration working, and I suspect that'll involve proposing more C APIs in for a later LLVM release, clues welcome.)
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
