Hi, Even when not using LLVMOrcAddLazilyCompiledIR() Orc crashes on platforms without indirect stub support. The reason for that is that its constructor dereferences a nullptr functor (IndirectStubsMgrBuilder): OrcCBindingsStack(TargetMachine &TM, std::unique_ptr<CompileCallbackMgr> CCMgr, IndirectStubsManagerBuilder IndirectStubsMgrBuilder) : ES(SSP), DL(TM.createDataLayout()), IndirectStubsMgr(IndirectStubsMgrBuilder()), CCMgr(std::move(CCMgr)), which is invoked by: LLVMOrcJITStackRef LLVMOrcCreateInstance(LLVMTargetMachineRef TM) { TargetMachine *TM2(unwrap(TM)); Triple T(TM2->getTargetTriple()); auto CompileCallbackMgr = orc::createLocalCompileCallbackManager(T, 0); auto IndirectStubsMgrBuilder = orc::createLocalIndirectStubsManagerBuilder(T); OrcCBindingsStack *JITStack = new OrcCBindingsStack( *TM2, std::move(CompileCallbackMgr), IndirectStubsMgrBuilder); return wrap(JITStack); } std::function<std::unique_ptr<IndirectStubsManager>()> createLocalIndirectStubsManagerBuilder(const Triple &T) { switch (T.getArch()) { default: return nullptr; ... } So, if any orc is used on a platform (e.g. powerpc) without stub support, orc can't be used in eager support either. It's not hard to fix this. We can either make createLocalIndirectSubsManagerBuilder() return orc::LocalIndirectStubsManager<orc::OrcGenericABI>>(); or have the C stack not construct IndirectStubsMgr until necessary. Any preference? I'd be awesome if we could get this fixed for 6.1, this is currently breaking postgres' JIT on PPC. I'm planning to update the orc unittests so a) they actually test aarch64, given that that should now be fully supported. b) split the tests into indirect / no jit at all capability, so crashes like this can be detected automatically in the future.
I've proposed a fix (thanks also to my colleague Thomas Munro that came up with the same approach) at: https://reviews.llvm.org/D44902 It'd be great if the fix could be backported so it'll be included in 6.1. Not sure if I'd include the test rework though.