search for: findmangledsymbol

...incorrectly for COFF in LLVM (see bug report from Russell Wallace: http://lists.llvm.org/pipermail/llvm-dev/2016-April/097964.html ). Applied to the current version of Kaleidoscope, he suggested to use "CompileLayer.findSymbolIn(H, Name, false)" in "KaleidoscopeJIT::findMangledSymbol" to also allow non-exported symbols. I fixed it by changing "COFFObjectFile::getSymbolFlags" in llvm-src/lib/Object/COFFObjectFile.cpp to additionally OR SymbolRef::SF_Exported to Result: > uint32_t COFFObjectFile::getSymbolFlags(DataRefImpl Ref) const { > CO...

...So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related function to my JIT context, and I create a lambda resolver as such: JITContext::addModule(…) { auto Resolver = createLambdaResolver( [&](const std::string &name) { // look up first in JIT'ed code if (auto sym = findMangledSymbol(name)) { return RuntimeDyld::SymbolInfo(sym.getAddress(), sym.getFlags()); return RuntimeDyld::SymbolInfo(nullptr); } // look up in added globals if (auto addr = getPointerToGlobalMapping(name)) { return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported); } // finally try to look up existing...

...> function to my JIT context, and I create a lambda resolver as such: >> >> JITContext::addModule(…) { >> >> auto Resolver = createLambdaResolver( >> [&](const std::string &name) { >> >> // look up first in JIT'ed code >> if (auto sym = findMangledSymbol(name)) { >> return RuntimeDyld::SymbolInfo(sym.getAddress(), >> sym.getFlags()); >> return RuntimeDyld::SymbolInfo(nullptr); >> } >> >> // look up in added globals >> if (auto addr = getPointerToGlobalMapping(name)) { >> return RuntimeDyld::SymbolInfo...

...and I create a lambda resolver as such: >>> >>> JITContext::addModule(…) { >>> >>> auto Resolver = createLambdaResolver( >>> [&](const std::string &name) { >>> >>> // look up first in JIT'ed code >>> if (auto sym = findMangledSymbol(name)) { >>> return RuntimeDyld::SymbolInfo(sym.getAddress(), >>> sym.getFlags()); >>> return RuntimeDyld::SymbolInfo(nullptr); >>> } >>> >>> // look up in added globals >>> if (auto addr = getPointerToGlobalMapping(name)) { >>&gt...

...create a lambda resolver as such: >>> >>> JITContext::addModule(…) { >>> >>> auto Resolver = createLambdaResolver( >>> [&](const std::string &name) { >>> >>> // look up first in JIT'ed code >>> if (auto sym = findMangledSymbol(name)) { >>> return RuntimeDyld::SymbolInfo(sym.getAddress(), >>> sym.getFlags()); >>> return RuntimeDyld::SymbolInfo(nullptr); >>> } >>> >>> // look up in added globals >>> if (auto addr = getPointerToGlobalMapping(name)) {...

Hi, I still can't get IR functions to JIT compile with the ORC JIT when they contain a call to the standard math library. Attached is a minimal exploit. The program uses the KaleidoscopeJIT.h that ships with LLVM 8 (except that I had to expose the Datalayout). It reads from the filesystem an IR file (filename "func_works.ll" or "func_cos_fails.ll) and asks the ORC JIT

We use an explicit relocation step to deal with this. We generate code into a temporary memory location, then relocate it into a reserved area of memory which is always within a small relative offset of other interesting code. This allows us to get pc relative calls. Philip On 03/30/2016 05:53 AM, Matt Godbolt wrote: > For what it's worth we did a similar thing, but > overrode

For what it's worth we did a similar thing, but overrode RTDyldMemoryManager directly This allowed us to control where the RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use small memory model and avoid the mov rax, xxxxxxx; call rax code generated for x86)*, and also override findSymbol() to have the same behaviour as described in 4). --matt * later issues in not