search for: getforcurrentprocess

...but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; > stream1.swap(stream2); > return 0; > } > > I didn't get undefined symbols error. I used > DynamicLibrarySearchGenerator::GetForCurrentProcess API to make symbols > from STL visible to ORC JIT. > > On Tue, 27 Aug 2019 at 20:36, Geoff Levner <glevner at gmail.com> wrote: > >> On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri >> <praveenvelliengiri at gmail.com> wrote: >> > >> > HI &gt...

Hi All, This was a quiet week -- the only significant ORC change was to the new TargetProcessControl API [1], which acquired the ability to load libraries and search for symbols in the target process in [2]. A new TargetProcessControl based definition generator is included to take advantage of this, and the LLJITWithTargetProcessControl example has been updated to include it. Regards, Lang. [1]

Hi Yafei, As david told, you can make the symbols of your host process visible to the JIT'd code through DynamicLibrarySearchGenerator::getForCurrentProcess. On Thu, 19 Sep 2019 at 00:46, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang Hames <lhames at gmail.com> , JITer of JITs. > > I believe there's some kind of resolver you can add that finds symbols in > the current process. Yes, lli uses some...

...DL = JTMB->getDefaultDataLayoutForTarget(); llvm::orc::IRCompileLayer CompileLayer(ES, ObjectLayer, llvm::orc::ConcurrentIRCompiler(std::move(*JTMB))); llvm::orc::MangleAndInterner Mangle(ES, *DL); ES.getMainJITDylib().setGenerator( llvm::cantFail(llvm::orc::DynamicLibrarySearchGenerator::GetForCurrentProcess(*DL))); // ... large part to generate IR code . if (llvm::verifyModule(*AST::getModule(), &llvm::errs())) { return 0; } else { std::cout << "Verified success\n"; } // run the generated IR code llvm::cantFail(CompileLayer.add(ES.getMainJITDylib(), llvm::orc:...

...symbol. I would expect LLJIT to resolve the global variable above to the address inside the host process, since it has linkage 'linkonce_odr'. However, it turns out that LLJIT resolved it as if it were a conventional global variable definition and gave it its own address (I have added 'GetForCurrentProcess' generator for symbol resolution of course). I can workaround this issue by making the symbol a declaration (drop the initializer, comdat and make the linkage external), but I'm wondering if it is expected behavior that LLJIT does not respect linkonce_odr specifier, since the documentation...

...e code snippets that show what I am doing: /* global syms is a array mapping names to function addresses */ ES->createJITDylib("<main>"); MainJD = ES->getJITDylibByName("<main>"); MainJD->addGenerator( cantFail(llvm::orc::DynamicLibrarySearchGenerator::GetForCurrentProcess( DL->getGlobalPrefix()))); auto &JD = *MainJD; llvm::orc::MangleAndInterner mangle(*ES, *this->DL); llvm::orc::SymbolMap Symbols; for (int i = 0; global_syms[i].name != nullptr; i++) { Symbols.insert({mangle(global_syms[i].name), llvm::JITEvaluatedSymbol(llvm::pointerToJITTarge...

.../* global syms is a array mapping names to function addresses */ >> >> ES->createJITDylib("<main>"); >> MainJD = ES->getJITDylibByName("<main>"); >> MainJD->addGenerator( >> cantFail(llvm::orc::DynamicLibrarySearchGenerator::GetForCurrentProcess( >> DL->getGlobalPrefix()))); >> auto &JD = *MainJD; >> llvm::orc::MangleAndInterner mangle(*ES, *this->DL); >> llvm::orc::SymbolMap Symbols; >> for (int i = 0; global_syms[i].name != nullptr; i++) { >> Symbols.insert({mangle(global_syms[i].na...

...the address for that symbol), Example: compiler are materializers. So to add symbols to your own JIT you can define them in JITDylib. For example, Suppose you want to add "your host process (on which JIT runs) symbols to the JIT". You can do JD.setGenerator(DynamicLibrarySearchGenerator::GetForCurrentProcess(DL.getGlobalPrefix())) Under hood, ORC normally search for your host symbols in the defGenerator if it can't find symbols anywhere else. You can look at core.cpp at line 1163 to see how it works! I highly recommended you to watch "Updating ORC for Concurrency" dev meeting talks, it...

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

Hi all, First of all, I want to say that I really appreciate all the work that's gone into LLVM, clang and the ORC API. I would be very unlikely to be doing my current project if they weren't available. I'm using the ORC API to JIT some C code (soon to be C++) on Windows. (I was on LLVM 8.0.0 but it didn't handle the 'allocator' attribute so I upgraded to LLVM 9.0.0.)

When I declare some functions in my IR code which belongs to the C standard library(printf for example), the JIT will report that symbol cannot found. So is there any way I can add these libraries to my JIT? P.S. When I using lli, the printf will work, I guess lli is a JIT(right?) and it somehow knows where to find the symbol printf -------------- next part -------------- An HTML attachment was

...addresses */ > > >> > > >> ES->createJITDylib("<main>"); > > >> MainJD = ES->getJITDylibByName("<main>"); > > >> MainJD->addGenerator( > > >> > cantFail(llvm::orc::DynamicLibrarySearchGenerator::GetForCurrentProcess( > > >> DL->getGlobalPrefix()))); > > >> auto &JD = *MainJD; > > >> llvm::orc::MangleAndInterner mangle(*ES, *this->DL); > > >> llvm::orc::SymbolMap Symbols; > > >> for (int i = 0; global_syms[i].name != nullptr; i++) { &...

Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol