search for: symbolinfo

...::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 process symbols, note // this works for...

...esolver 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); >> } >...

...t;> 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...

...ITContext::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, JI...

...// Set up compilation if (orc) { auto Resolver = llvm::orc::createLambdaResolver( // External lookup functor [&](const std::string &name) { if (auto Sym = Compilelayer.findSymbol(name, true)) return llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); // If not found as a symbol, look up in current process. // Why doesn't this work? if (auto Addr = llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name)) return llvm::RuntimeDyld::SymbolI...

Dear LLVM-Mailing list (again), I still have another beginners question in my mind - thank you for your patience. Again I was playing around, but this time with llvm::Function. In an older question I learned, that I can replace a llvm::Function directly with an address. llvm::Function *function = mainModue->getFunction("puts"); function->replaceAllUsesWith(

...9; anymore, which leads to the crash. Given that my assumption is correct what can we do about this? Is there anything that can be done to cover this case inside of the Orc engine? Currently, I worked around this problem by resolving atexit to my custom function that does nothing. RuntimeDyld::SymbolInfo findSymbol(const std::string &Name) { if (Name == "_atexit") { return findSymbol("mull_custom_test_at_exit"); } if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess(Name)) return RuntimeDyld::SymbolInfo(SymAddr, JITSymbolFlags::Exported)...

...if (orc) { > auto Resolver = llvm::orc::createLambdaResolver( > // External lookup functor > [&](const std::string &name) { > if (auto Sym = Compilelayer.findSymbol(name, true)) > return llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); > // If not found as a symbol, look up in current process. > // Why doesn't this work? > if (auto Addr = llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name)) > return llvm::...

...auto Resolver = llvm::orc::createLambdaResolver( >> // External lookup functor >> [&](const std::string &name) { >> if (auto Sym = Compilelayer.findSymbol(name, true)) >> return >> llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); >> // If not found as a symbol, look up in current process. >> // Why doesn't this work? >> if (auto Addr = >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name)) >>...

...t; auto Resolver = llvm::orc::createLambdaResolver( >> // External lookup functor >> [&](const std::string &name) { >> if (auto Sym = Compilelayer.findSymbol(name, true)) >> return llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); >> // If not found as a symbol, look up in current process. >> // Why doesn't this work? >> if (auto Addr = llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name)) >>...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

Tried that, still didn't work. Then I tried making a direct API call, GetProcAddress(GetModuleHandle(0),"foo") And this works if and only if __declspec(dllexport) is supplied. So it looks like we were both right. On Sat, Apr 2, 2016 at 9:29 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Have you tried to add dllexport? > > On Sat, Apr 2, 2016 at 4:23 PM

...orModule call, the findExistingSymbol is invoked. For some reason it cannot find my symbol. My symbol exists in the Module that was used as input for generateCodeForModule. It uses the object cache and that code was valid and generated in the previous run. I tried to traced further in RuntimeDyld::SymbolInfo getSymbol() and could see that the GlobalSymbolTable did not contained my symbol. I obviously forgot something or did something wrong, what puzzeld me is that is quite semi-random. Even the most simple statements such as int x = 1; (no dependencies) sometime fails. I did not hardcode any ptrs in...

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

Hi Lang, thanks for announcing. Would be great if you could send another short notice as soon as the actual patch exists. Best, Stefan Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev: > Hi All, > > I'm going to be making some API breaking changes to the ORC APIs, and > to the RuntimeDyld class (which underlies MCJIT). The changes may > affect MCJIT clients but are unlikely

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

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

Hi Again, I'm a little confused regarding what is the exact Orc's functions I should use in order to save the functions code in a code cache so it could be later replaced with different versions of it and I appreciate your help. Just a reminder I want to dynamically recompile the program based on profile collected at the run-time. I would like to start executing the program from the