search for: getsymboladdressinprocess

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160402/4bb593a4/attachment.html>

...managed to extract from Kaleidoscope one particular thing >> that it seems to me should be working and isn't. Given the global >> declaration >> >> extern "C" void foo() {} >> >> within the same program I have >> >> RTDyldMemoryManager::getSymbolAddressInProcess("foo") >> >> And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/ll...

Hi Andy, I haven't tested this on Linux, but on MacOS the RuntimeDyldMemorManager::getSymbolAddressInProcess method should find symbol addresses in the host program, including symbols from static archives linked into the program. However, one gotcha is that the symbol has to be reachable from main, otherwise the linker may strip it from the final executable. Do you have a test-case that I could try to re...

...After some fiddling with it, it does in fact look like it works as you > describe Lang. > > The trick was you had to call > > llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); > > to add the currently running process before calling > > llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name);. > > Also, all of the function needs to be declared as extern C to avoid name > mangling. > > I however think that adding the addGlobalMapping/getPointerToGlobalMapping > functions to the ORC kaleidoscope examples is very useful, as for example > one wants a set of priva...

...es in fact look like it works as you describe Lang. >> >> The trick was you had to call >> >> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >> >> to add the currently running process before calling >> >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name);. >> >> Also, all of the function needs to be declared as extern C to avoid name mangling. >> >> I however think that adding the addGlobalMapping/getPointerToGlobalMapping functions to the ORC kaleidoscope examples is very useful, as for example one wants a set of p...

...balMapping(name)) { return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported); } // finally try to look up existing process symbols, note // this works for symbols loaded in shared libraries, but // does NOT seem to find symbols declared in the executable. if (auto Addr = RTDyldMemoryManager::getSymbolAddressInProcess(name)) { return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported); } }, [](const std::string &S) { return nullptr; } ); } Here the getPointerToGlobalMapping function looks in a uint64 StringMap into which values are added via the addGlobalMapping functions. This approach seems to be wo...

...t; You're basically there, but you're hitting a couple of subtle issues: > > (1) On both platforms you'll want to call llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) at program startup. This makes exported symbols in the main program searchable by RTDyldMemoryManager::getSymbolAddressInProcess (important for making 'sqr' findable on any platform). > > (2) On Linux (if I understand correctly) symbols aren't exported from the main process by default, so even if you've called DynamicLibrary::LoadLibraryPermanently, sqr won't show up. To fix this you can add -Wl,ex...

...layer.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::SymbolInfo(Addr, llvm::JITSymbolFlags::Exported); return llvm::RuntimeDyld::SymbolInfo(nullptr); }, // Dylib lookup functor [&](const std::string &name) { return nullptr; } );...

...Symbol(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)))...

...basically there, but you're hitting a couple of subtle issues: > > (1) On both platforms you'll want to call > llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) at program > startup. This makes exported symbols in the main program searchable by > RTDyldMemoryManager::getSymbolAddressInProcess (important for making 'sqr' > findable on any platform). > > (2) On Linux (if I understand correctly) symbols aren't exported from the > main process by default, so even if you've called > DynamicLibrary::LoadLibraryPermanently, sqr won't show up. To fix this you...

...return JITSymbol(nullptr); }, [](const std::string &Name) { if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess(Name)) return JITSymbol(SymAddr, JITSymbolFlags::Exported); return JITSymbol(nullptr); }); // Add the set to the JIT with the resolver we created ab...

...ntf("FLUSH :0\n"); > if (auto Sym = CompileLayer.findSymbol(Name, false)) > return Sym; > return JITSymbol(nullptr); > } > > Then, if it doesn't find a definition there, it falls back to searching in > the current process (this is what RTDyldMemoryManager::getSymbolAddressInProcess > does): > > [](const std::string &S) { > printf("PLUSH :0\n"); > if (auto SymAddr = > RTDyldMemoryManager::getSymbolAddressInProcess(S)) > return JITSymbol(SymAddr, JITSymbolFlags::Exported); > return JITSymbol(nullptr); > } > > If,...

...39;re basically there, but you're hitting a couple of subtle issues: >> >> (1) On both platforms you'll want to call llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) at program startup. This makes exported symbols in the main program searchable by RTDyldMemoryManager::getSymbolAddressInProcess (important for making 'sqr' findable on any platform). >> >> (2) On Linux (if I understand correctly) symbols aren't exported from the main process by default, so even if you've called DynamicLibrary::LoadLibraryPermanently, sqr won't show up. To fix this you can ad...

...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), &...

...}, > > [](const std::string &Name) { > > if (auto SymAddr = > > RTDyldMemoryManager:: > getSymbolAddressInProcess(Name)) > > return > JITSymbol(SymAddr, JITSymbolFlags::Exported); > > return JITSymbol(nullptr); > > }); > > > > > >...

In uint64_t RTDyldMemoryManager::getSymbolAddressInProcess(const std::string &Name) { there is reference to morestack: #if defined(__i386__) || defined(__x86_64__) // __morestack lives in libgcc, a static library. if (&__morestack && Name == "__morestack") return (uint64_t)&__morestack; #endif #endif // __linux__...

...$ nm lib/liblldb.so | grep morestack U __morestack resulting in the failure linking bin/lldb in that case. > David > > On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: > >> In uint64_t >> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string &Name) >> { >> >> there is reference to morestack: >> >> >> >> #if defined(__i386__) || defined(__x86_64__) >> // __morestack lives in libgcc, a static library. >> if (&__morestack && Name == "__morest...

...er uses > // GetProcAddress and standard libraries like msvcrt.dll use names > // with and without "_" (for example "_itoa" but "sin"). > if (Name.length() > 2 && Name[0] == '_') > if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess( > Name.substr(1))) > return JITSymbol(SymAddr, JITSymbolFlags::Exported); > #endif > > return nullptr; > } - "ready> sin(1.0); Read top-level expression: define double @2() { entry: ret double 0x3FEAED548F090CEE }...

...sulting in the failure linking bin/lldb in that case. >> >> >>> David >>> >>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li <xinliangli at gmail.com> >>> wrote: >>> >>>> In uint64_t >>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string >>>> &Name) { >>>> >>>> there is reference to morestack: >>>> >>>> >>>> >>>> #if defined(__i386__) || defined(__x86_64__) >>>> // __morestack lives in libgcc, a static library. &...

...t;>>> >>>>> David >>>>> >>>>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li < >>>>> xinliangli at gmail.com> wrote: >>>>> >>>>>> In uint64_t >>>>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string >>>>>> &Name) { >>>>>> >>>>>> there is reference to morestack: >>>>>> >>>>>> >>>>>> >>>>>> #if defined(__i386__) || defined(__x86_64__) >>>&g...