Christophe Duvernois via llvm-dev
2017-Jul-27 13:38 UTC
[llvm-dev] llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return findSymbol(MangledName, CheckFunctionsOnly).getAddress();}* Now with the current implementation (llvm 5.0 rc1 tag) : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { if (auto AddrOrErr = Sym.getAddress()) return *AddrOrErr; else { report_fatal_error(AddrOrErr.takeError()); } } else { report_fatal_error(Sym.takeError()); }}* If the function findSymbol return nullptr, we are executing report_fatal_error and kill everything :( What is the reason for this change? Is this a bug? If this is intended, how can we check from the ExecutionEngine that the symbol already exists? Regards, Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170727/e8838910/attachment.html>
Daniel Neilson via llvm-dev
2017-Jul-27 14:06 UTC
[llvm-dev] llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
Relevant change: commit a81793582b3c47869680d354a97d59c55779c349 Author: Lang Hames <lhames at gmail.com<mailto:lhames at gmail.com>> Date: Fri Jul 7 02:59:13 2017 +0000 [ORC] Errorize the ORC APIs. This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 307350 91177308-0d34-0410-b5e6-96231b3b80d8 On Jul 27, 2017, at 8:38 AM, Christophe Duvernois via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return findSymbol(MangledName, CheckFunctionsOnly).getAddress(); } Now with the current implementation (llvm 5.0 rc1 tag) : uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { if (auto AddrOrErr = Sym.getAddress()) return *AddrOrErr; else { report_fatal_error(AddrOrErr.takeError()); } } else { report_fatal_error(Sym.takeError()); } } If the function findSymbol return nullptr, we are executing report_fatal_error and kill everything :( What is the reason for this change? Is this a bug? If this is intended, how can we check from the ExecutionEngine that the symbol already exists? Regards, Christophe _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170727/ddd71b87/attachment.html>
Hans Wennborg via llvm-dev
2017-Jul-27 17:37 UTC
[llvm-dev] llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
+Lang And should there be something in the release notes about this? On Thu, Jul 27, 2017 at 7:06 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Relevant change: > > commit a81793582b3c47869680d354a97d59c55779c349 > Author: Lang Hames <lhames at gmail.com> > Date: Fri Jul 7 02:59:13 2017 +0000 > > [ORC] Errorize the ORC APIs. > > This patch updates the ORC layers and utilities to return and propagate > llvm::Errors where appropriate. This is necessary to allow ORC to safely > handle > error cases in cross-process and remote JITing. > > > > git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 307350 > 91177308-0d34-0410-b5e6-96231b3b80d8 > > > > > On Jul 27, 2017, at 8:38 AM, Christophe Duvernois via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) > when the symbol is not found : > > uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool > CheckFunctionsOnly) { > std::string MangledName; > { > raw_string_ostream MangledNameStream(MangledName); > Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); > } > return findSymbol(MangledName, CheckFunctionsOnly).getAddress(); > } > > Now with the current implementation (llvm 5.0 rc1 tag) : > > uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool > CheckFunctionsOnly) { > std::string MangledName; > { > raw_string_ostream MangledNameStream(MangledName); > Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); > } > if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { > if (auto AddrOrErr = Sym.getAddress()) > return *AddrOrErr; > else { > report_fatal_error(AddrOrErr.takeError()); > } > } else { > report_fatal_error(Sym.takeError()); > } > } > > If the function findSymbol return nullptr, we are executing > report_fatal_error and kill everything :( > > What is the reason for this change? Is this a bug? > > If this is intended, how can we check from the ExecutionEngine that the > symbol already exists? > > > Regards, > Christophe > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Seemingly Similar Threads
- [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
- [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
- [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
- [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
- [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h