Frank Winter via llvm-dev
2018-Jun-28 20:49 UTC
[llvm-dev] Since MCJIT I can't get libm functions to work
Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote:> Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > > sys::DynamicLibrary::LoadLibraryPermanently(nullptr); > > If it doesn't help, then you may try compiling your host program with -rdynamic, otherwise dlsym may not see all the symbols. At least it was the case for me on Linux. > > I hope it helps. > > Cheers, > Alex. > >> On 28. Jun 2018, at 21:40, Frank Winter via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. >> >> A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process space. >> >> The generated modules would declare external functions like >> >> declare float @cosf(float) >> >> and would call it like: >> >> %17 = call float @cosf(float %16) >> >> The datalayout is set to >> >> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" >> >> The code snippet that adds the module is pretty much from the JIT tutorial: >> >> auto Resolver = llvm::orc::createLambdaResolver( >> [&](const std::string &Name) { >> if (auto Sym = CompileLayer.findSymbol(Name, false)) >> return Sym; >> return llvm::JITSymbol(nullptr); >> }, >> [](const std::string &Name) { >> if (auto SymAddr >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(Name)) >> return llvm::JITSymbol(SymAddr, llvm::JITSymbolFlags::Exported); >> return llvm::JITSymbol(nullptr); >> }); >> >> cantFail(CompileLayer.addModule(std::move(M), >> std::move(Resolver))); >> >> When running the program I receive the following error: >> >> LLVM ERROR: Program used external function 'cosf' which could not be resolved! >> >> This is on an Intel i7 CPU with LLVM targets configured as "X86". >> >> Adding the '-lm' and '-ldl' option to the linker command that links the final program doesn't help. (I even called the 'cosf' function by hand in the host code to make sure it is mapped - didn't change the behavior of the MCJIT resolver.) >> >> Any ideas? >> >> >> Best wishes, >> >> Frank >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Lang Hames via llvm-dev
2018-Jun-28 21:27 UTC
[llvm-dev] Since MCJIT I can't get libm functions to work
Ahh. It is the *other* in-process-symbol-lookup gotcha. I will think about adding a convenience option for that. Thanks Alex! -- Lang. On Thu, Jun 28, 2018 at 1:49 PM Frank Winter via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Alex, > > loading the symbols explicitly helped. With this the build process > doesn't need any additional linker flags. Very nice. > > Thanks, > Frank > > > On 06/28/2018 04:38 PM, Alex Denisov wrote: > > Hi Frank, > > > > If I am not mistaken it doesn't look in the whole process space by > default. > > Please, try loading all the symbols explicitly: > > > > sys::DynamicLibrary::LoadLibraryPermanently(nullptr); > > > > If it doesn't help, then you may try compiling your host program with > -rdynamic, otherwise dlsym may not see all the symbols. At least it was the > case for me on Linux. > > > > I hope it helps. > > > > Cheers, > > Alex. > > > >> On 28. Jun 2018, at 21:40, Frank Winter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> I am upgrading our JIT application to use LLVM 6.0.0, and with this > transition I am making the move to use the new MCJIT facility. > >> > >> A problem I am encountering is that the math functions from libm are > not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT > class which first searches the present modules and, if that is > unsuccessful, continues the search in the whole process space. > >> > >> The generated modules would declare external functions like > >> > >> declare float @cosf(float) > >> > >> and would call it like: > >> > >> %17 = call float @cosf(float %16) > >> > >> The datalayout is set to > >> > >> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" > >> > >> The code snippet that adds the module is pretty much from the JIT > tutorial: > >> > >> auto Resolver = llvm::orc::createLambdaResolver( > >> [&](const std::string &Name) { > >> if (auto Sym > CompileLayer.findSymbol(Name, false)) > >> return Sym; > >> return llvm::JITSymbol(nullptr); > >> }, > >> [](const std::string &Name) { > >> if (auto SymAddr > >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(Name)) > >> return llvm::JITSymbol(SymAddr, > llvm::JITSymbolFlags::Exported); > >> return llvm::JITSymbol(nullptr); > >> }); > >> > >> cantFail(CompileLayer.addModule(std::move(M), > >> std::move(Resolver))); > >> > >> When running the program I receive the following error: > >> > >> LLVM ERROR: Program used external function 'cosf' which could not be > resolved! > >> > >> This is on an Intel i7 CPU with LLVM targets configured as "X86". > >> > >> Adding the '-lm' and '-ldl' option to the linker command that links the > final program doesn't help. (I even called the 'cosf' function by hand in > the host code to make sure it is mapped - didn't change the behavior of the > MCJIT resolver.) > >> > >> Any ideas? > >> > >> > >> Best wishes, > >> > >> Frank > >> > >> > >> > >> _______________________________________________ > >> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180628/0b162ec4/attachment.html>
Alex Denisov via llvm-dev
2018-Jun-29 08:22 UTC
[llvm-dev] Since MCJIT I can't get libm functions to work
Great! I'm glad that it worked :)> On 28. Jun 2018, at 23:27, Lang Hames <lhames at gmail.com> wrote: > > Ahh. It is the other in-process-symbol-lookup gotcha. > > I will think about adding a convenience option for that. > > Thanks Alex! > > -- Lang. > > On Thu, Jun 28, 2018 at 1:49 PM Frank Winter via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Alex, > > loading the symbols explicitly helped. With this the build process > doesn't need any additional linker flags. Very nice. > > Thanks, > Frank > > > On 06/28/2018 04:38 PM, Alex Denisov wrote: > > Hi Frank, > > > > If I am not mistaken it doesn't look in the whole process space by default. > > Please, try loading all the symbols explicitly: > > > > sys::DynamicLibrary::LoadLibraryPermanently(nullptr); > > > > If it doesn't help, then you may try compiling your host program with -rdynamic, otherwise dlsym may not see all the symbols. At least it was the case for me on Linux. > > > > I hope it helps. > > > > Cheers, > > Alex. > > > >> On 28. Jun 2018, at 21:40, Frank Winter via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> > >> I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. > >> > >> A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process space. > >> > >> The generated modules would declare external functions like > >> > >> declare float @cosf(float) > >> > >> and would call it like: > >> > >> %17 = call float @cosf(float %16) > >> > >> The datalayout is set to > >> > >> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" > >> > >> The code snippet that adds the module is pretty much from the JIT tutorial: > >> > >> auto Resolver = llvm::orc::createLambdaResolver( > >> [&](const std::string &Name) { > >> if (auto Sym = CompileLayer.findSymbol(Name, false)) > >> return Sym; > >> return llvm::JITSymbol(nullptr); > >> }, > >> [](const std::string &Name) { > >> if (auto SymAddr > >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(Name)) > >> return llvm::JITSymbol(SymAddr, llvm::JITSymbolFlags::Exported); > >> return llvm::JITSymbol(nullptr); > >> }); > >> > >> cantFail(CompileLayer.addModule(std::move(M), > >> std::move(Resolver))); > >> > >> When running the program I receive the following error: > >> > >> LLVM ERROR: Program used external function 'cosf' which could not be resolved! > >> > >> This is on an Intel i7 CPU with LLVM targets configured as "X86". > >> > >> Adding the '-lm' and '-ldl' option to the linker command that links the final program doesn't help. (I even called the 'cosf' function by hand in the host code to make sure it is mapped - didn't change the behavior of the MCJIT resolver.) > >> > >> Any ideas? > >> > >> > >> Best wishes, > >> > >> Frank > >> > >> > >> > >> _______________________________________________ > >> 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-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180629/a871437c/attachment.sig>