Open andreas-schwab opened 2 months ago
@llvm/issue-subscribers-backend-risc-v
Author: Andreas Schwab (andreas-schwab)
@llvm/issue-subscribers-orcjit
Author: Andreas Schwab (andreas-schwab)
ExternalSymbolMap=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1112
this=0x2443f6c0, Result=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1240
CallableAddr=0x243a91b0, Params=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:221
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:385
InternedResult=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:43
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:221
Params=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:385
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:204
CallableAddr=<optimized out>, Params=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:221
Params=std::unique_ptr<llvm::orc::Task> = {...})
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:385
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/Core.h:1603
ES=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:214
MR=..., Resolved=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:1047
MR=..., this=<optimized out>, Symbols=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:3034
this=0x7e29cdc87607ee00, Symbols=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/Core.h:1965
this=<optimized out>,
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...})
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:274
this=<optimized out>)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:1921
CallableAddr=<optimized out>, Params=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:221
Params=std::unique_ptr<llvm::orc::Task> = {...})
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:385
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/Core.h:1603
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2309
Q=std::shared_ptr<llvm::orc::AsynchronousSymbolQuery> (use count 2, weak count 0) = {...}, RegisterDependencies=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2919
this=<optimized out>, IPLS=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:580
this=<optimized out>,
IPLS=std::unique_ptr<llvm::orc::InProgressLookupState> = {...}, Err=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2675
K=llvm::orc::LookupKind::Static, SearchOrder=..., Symbols=...,
RequiredState=llvm::orc::SymbolState::Resolved, NotifyComplete=...,
RegisterDependencies=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2147
this=0x3fcb1f6750, Symbols=..., OnResolved=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:54
Info=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1265
OnEmitted=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1472
this=0x2434bea0, R=..., O=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:189
this=0x24350b00,
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...},
O=std::unique_ptr<llvm::MemoryBuffer> = {...})
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/ObjectTransformLayer.cpp:40
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...},
TSM=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/IRCompileLayer.cpp:40
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...},
TSM=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/IRTransformLayer.cpp:25
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...},
TSM=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/IRTransformLayer.cpp:25
R=std::unique_ptr<llvm::orc::MaterializationResponsibility> = {...})
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Layer.cpp:158
this=<optimized out>)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:1921
CallableAddr=<optimized out>, Params=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:221
Params=std::unique_ptr<llvm::orc::Task> = {...})
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ADT/FunctionExtras.h:385
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/Core.h:1603
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2309
Q=std::shared_ptr<llvm::orc::AsynchronousSymbolQuery> (use count 2, weak count 0) = {...}, RegisterDependencies=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2919
this=<optimized out>, IPLS=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:580
this=<optimized out>,
IPLS=std::unique_ptr<llvm::orc::InProgressLookupState> = {...}, Err=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2675
K=llvm::orc::LookupKind::Static, SearchOrder=..., Symbols=...,
RequiredState=llvm::orc::SymbolState::Ready, NotifyComplete=...,
RegisterDependencies=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2147
SearchOrder=std::vector of length 1, capacity 1 = {...}, Symbols=...,
K=llvm::orc::LookupKind::Static,
RequiredState=llvm::orc::SymbolState::Ready, RegisterDependencies=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2184
this=0x240e7110, SearchOrder=std::vector of length 1, capacity 1 = {...},
Name=..., RequiredState=llvm::orc::SymbolState::Ready)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/Core.cpp:2209
this=<optimized out>, JD=..., Name=...)
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/LLJIT.cpp:874
this=0x24345830, JD=..., Name=...)
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/LLJIT.h:164
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/LLJIT.h:176
at /usr/src/debug/llvm-18.1.8.src/include/llvm/ExecutionEngine/Orc/LLJIT.h:181
Name=<optimized out>, Name@entry=0x242e3a90 "evalexpr_0_3")
at /usr/src/debug/llvm-18.1.8.src/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp:1001
IIUC RuntimeDyld is part of MC JIT and should not be used by ORC JIT.
ORC can use RuntimeDyld or JITLink as the underlying JIT linker.
RuntimeDyld does not support RISC-V, at least not in llvm.org/main -- Is your JIT'd code actually targeting RISC-V?
2024-08-28 18:08:52.635 CEST client backend[48551] pg_regress/boolean DEBUG: LLVMJIT detected CPU "sifive-u74", with features ""
ORC can use RuntimeDyld or JITLink as the underlying JIT linker.
How does it decide?
What is the JITLink equivalent of LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager?
I had this issue on Gentoo and have a old patch that I haven't got time to update. It is probably needed to be rebased/modified. PS: pls ignore the comments I made on that thread about riscv ABIs. It is probably no longer valid or wrong.
https://www.postgresql.org/message-id/flat/20220829074622.2474104-1-alex.fan.q%40gmail.com
ORC can use RuntimeDyld or JITLink as the underlying JIT linker.
How does it decide?
LLJIT
uses the following test(s): https://github.com/llvm/llvm-project/blob/2eeeff842f993a694159183a2834b4d305549cad/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp#L776
If you're constructing your JIT manually then it just depends on whether you use an RTDyldObjectLinkingLayer
(RuntimeDyld), or ObjectLinkingLayer
(JITLink).
In LLVM 20 we'll be aiming to switch the default to JITLink, with fallbacks to RuntimeDyld for architectures where JITLink is unavailable / under-development.
What is the JITLink equivalent of LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager?
There isn't one yet, but we could easily add an LLVMOrcCreateObjectLinkingLayerWithInProcessMemoryManager
API if you're able to try it out?
WARNING: error during JITing: In graph pg-jitted-objectbuffer, section .text: relocation target "CurrentMemoryContext" at address 0x802398 is out of range of R_RISCV_PCREL_HI20 fixup at 0x3f8c165162 (evalexpr_0_0, 0x3f8c165000 + 0x162) ERROR: failed to look up symbol "evalexpr_0_0": Failed to materialize symbols: { (main, { evalexpr_0_11, evalexpr_0_13, evalexpr_0_5, evalexpr_0_10, evalexpr_0_4, evalexpr_0_7, evalexpr_0_0, evalexpr_0_9, evalexpr_0_3, evalexpr_0_1 }) }
WARNING: error during JITing: In graph pg-jitted-objectbuffer, section .text: relocation target "CurrentMemoryContext" at address 0x802398 is out of range of R_RISCV_PCREL_HI20 fixup at 0x3f8c166182 (evalexpr_0_0, 0x3f8c166000 + 0x182) ERROR: failed to look up symbol "evalexpr_0_1": Failed to materialize symbols: { (main, { evalexpr_0_1, evalexpr_0_0 }) }
How is CurrentMemoryContext
declared within the JIT'd module? And what code / relocation model are you using for compilation?
The source is using the default model. The problem is that RISC-V's default isn't large, which is perfectly fine for normal compiled code but generally too restrictive for a JIT. We'll want to do something similar to what getEffectiveAArch64CodeModel does (the AArch64 and RISC-V code models are similar in their restrictions) when it sees a JIT is in use and pick a different code model, likely by changing RISCVTargetMachine to pass JIT ? CodeModel::Large : CodeModel::Small
to getEffectiveCodeModel, though we don't actually support a large code model currently (it's in review). Until then maybe forcing PIC will work, as that will add GOT indirection.
How are small/static references to external symbols handled by AOT compilation? Presumably these could be at any place in the address range too?
Or is the default Small / PIC? In which case we should have the JIT default to that too.
In general we assume that the JIT is subject to the same constraints as regular compilation: code within a JITDylib must be within the range specified by the code model, and in general external references may be located anywhere in memory.
Helped by a combination of copy relocations and PLTs. You can do PLTs for a JIT, but you can't do copy relocations for existing symbols.
but you can't do copy relocations for existing symbols.
Where are copy relocations documented? The RISCV ABI doc that I found wasn't much help.
I'm assuming CurrentMemoryContext
is an external data reference -- how are they handled in small / static? E.g.
extern int x;
int getX() { return x; }
just produces R_RISCV_GOT_HI20
/ R_RISCV_PCREL_LO12_I
when I compile it with clang --target=riscv64-linux -static -mcmodel=small -c
.
@andreas-schwab Sounds like it might be worth specifying PIC relocations.
(thought eventually I hope the JIT will support the default code / relocation model for RISCV, since that makes it easy for users to import precompiled libraries).
That's what the patch does?
+#ifdef __riscv
@alexfanqi's patch? Looks like iit -- but I think the default code model (probably small?) should be fine, as long as the reloc model is PIC.
Where are copy relocations documented? The RISCV ABI doc that I found wasn't much help.
Finally got around to looking for this again: https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter4-84604/index.html
You can do PLTs for a JIT, but you can't do copy relocations for existing symbols.
I think the full answer to this is: JIT'd code is always shared library code (conceptually), since it's necessarily loaded after the main executable, and is distinct from it. I'll make PIC the default relocation model for ELF in LLJIT.
At a stretch we could support copy relocations in JIT'd code under two conditions:
Interesting cases to consider, but I don't think they're a priority right now.
WARNING: error during JITing: In graph pg-jitted-objectbuffer, section .text: relocation target "CurrentMemoryContext" at address 0x555555e84b00 is out of range of R_RISCV_PCREL_HI20 fixup at 0x7f221c4bb1e4 (evalexpr_0_0, 0x7f221c4bb000 + 0x1e4)
WARNING: error during JITing: In graph pg-jitted-objectbuffer, section .text: relocation target "CurrentMemoryContext" at address 0x555555e84b00 is out of range of R_RISCV_PCREL_HI20 fixup at 0x7f221c4bb1e4 (evalexpr_0_0, 0x7f221c4bb000 + 0x1e4)
What code / relocation model did this occur under?
+#ifdef __riscv
With LLVMCodeModelLarge nothing changes, still the same JIT error.
With what version? RISC-V only gained large code model support recently in main, with older versions falling back I assume to medium aka medany.
I'm testing with LLVM 18.
When postgresql is configured with --with-llvm the regression testsuite causes a lot of crashed that all look like this:
0 std::_Deque_iterator<llvm::SectionEntry, llvm::SectionEntry&, llvm::SectionEntry*>::_M_set_node (__new_node=0x19db8a08, this=)
1 std::_Deque_iterator<llvm::SectionEntry, llvm::SectionEntry&, llvm::SectionEntry*>::operator+= (__n=, this=)
2 std::operator+ (x=..., n=)
3 std::_Deque_iterator<llvm::SectionEntry, llvm::SectionEntry&, llvm::SectionEntry*>::operator[] (this=, __n=)
4 std::deque<llvm::SectionEntry, std::allocator >::operator[] (this=, __n=)
5 llvm::RuntimeDyldELF::computePlaceholderAddress (this=,
6 0x0000003f83fc33ca in llvm::RuntimeDyldImpl::resolveRelocationList (
7 llvm::RuntimeDyldImpl::applyExternalSymbolRelocations (this=0xb117b80,
8 0x000000000a287310 in ?? ()
IIUC RuntimeDyld is part of MC JIT and should not be used by ORC JIT.