search for: generatecodeformodule

...us using the cached objects) the executionengine->getFunctionAddress() *sometimes *returns nullptr for a function that exists in the cache. I've traced into the cache call, and could see that my getObject() returned the right object. The object is loaded and no error was reported by ( MCJIT::generateCodeForModule(Module *M)): // Load the object into the dynamic linker. // MCJIT now owns the ObjectImage pointer (via its LoadedObjects list). ErrorOr<std::unique_ptr<object::ObjectFile>> LoadedObject = object::ObjectFile::createObjectFile(ObjectToLoad->getMemBufferRef()); std::unique...

...achine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded". Am I right? Regards. rodia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/bdea2e51/attachment.html>

...odule&) + 4294121888 [ 3149s] 12 libLLVMCore.so 0x00003fff7f35d120 llvm::legacy::PassManager::run(llvm::Module&) + 4294123632 [ 3149s] 13 libLLVMMCJIT.so 0x00003fff7eff6a20 llvm::MCJIT::emitObject(llvm::Module*) + 4294875216 [ 3149s] 14 libLLVMMCJIT.so 0x00003fff7eff6dfc llvm::MCJIT::generateCodeForModule(llvm::Module*) + 4294876180 [ 3149s] 15 libLLVMMCJIT.so 0x00003fff7eff7674 llvm::MCJIT::finalizeObject() + 4294878228 [ 3149s] 16 lli 0x000000001000cf9c main + 4294831444 [ 3149s] 17 libc.so.6 0x00003fff7e5f796c [ 3149s] 18 libc.so.6 0x00003fff7e5f7b74 __libc_start_m...

...uot; module will never be generated if it >> doesn't depend on the first one. More over it will cause a crash if entry >> point isn't in first module. Implementation of finalizeObject using for >> loop will omit every other module in OwnedModules, because function >> generateCodeForModule moves module form "added" to "loaded". >> Am I right? >> >> Regards. >> >> rodia >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu...

...o 0x00003fff7f35d120 > > llvm::legacy::PassManager::run(llvm::Module&) + 4294123632 > > [ 3149s] 13 libLLVMMCJIT.so 0x00003fff7eff6a20 > > llvm::MCJIT::emitObject(llvm::Module*) + 4294875216 > > [ 3149s] 14 libLLVMMCJIT.so 0x00003fff7eff6dfc > > llvm::MCJIT::generateCodeForModule(llvm::Module*) + 4294876180 > > [ 3149s] 15 libLLVMMCJIT.so 0x00003fff7eff7674 > > llvm::MCJIT::finalizeObject() + 4294878228 > > [ 3149s] 16 lli 0x000000001000cf9c main + 4294831444 > > [ 3149s] 17 libc.so.6 0x00003fff7e5f796c > > [ 3149s] 18 l...

Hi Lang, I'm using Windows. I was parsing an IR-File and added the Module to the ExectuionEngine. If I than searched for a function, I just got 0. But when the module had a main, I got an address. I solved the problem via a call to "generateCodeForModule". The JIT didn't even called my SymbolResolver in this special case. Could you please tell me, if there is a way to allocate the memory for the codemodules more precise? I would like to allocate the memory for strings from a separated memory-pool. But how can I detect a string? The onl...

...x000000010108466d libjvm.dylib`llvm::legacy::PassManager::run() + 13 at LegacyPassManager.cpp:1746 frame #18: 0x0000000100eeaf8c libjvm.dylib`llvm::MCJIT::emitObject(this=0x0000000106fa69a0, M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 frame #19: 0x0000000100eeb2d3 libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 frame #20: 0x0000000100eec022 libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, CheckFunctionsOnly=true) + 58 at MCJIT.cpp:279 frame #21:...

...ib`llvm::legacy::PassManager::run() + 13 at > LegacyPassManager.cpp:1746 > frame #18: 0x0000000100eeaf8c > libjvm.dylib`llvm::MCJIT::emitObject(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 > frame #19: 0x0000000100eeb2d3 > libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 > frame #20: 0x0000000100eec022 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) > [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, > CheckFunctionsOnly=true) + 58 at MCJI...

...ib`llvm::legacy::PassManager::run() + 13 at > LegacyPassManager.cpp:1746 > frame #18: 0x0000000100eeaf8c > libjvm.dylib`llvm::MCJIT::emitObject(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 > frame #19: 0x0000000100eeb2d3 > libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 > frame #20: 0x0000000100eec022 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) > [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, > CheckFunctionsOnly=true) + 58 at MCJI...

...t 7:03 AM, <bjoern.gaier at horiba.com> wrote: Hi Lang, I'm using Windows. I was parsing an IR-File and added the Module to the ExectuionEngine. If I than searched for a function, I just got 0. But when the module had a main, I got an address. I solved the problem via a call to "generateCodeForModule". The JIT didn't even called my SymbolResolver in this special case. Could you please tell me, if there is a way to allocate the memory for the codemodules more precise? I would like to allocate the memory for strings from a separated memory-pool. But how can I detect a string? The on...

Context: We use MCJIT to generate machine code in our LLVM based JIT compiler. The code generation process has roughly 5 steps: 0. Generate and optimize LLVM IR. 1. Call generateCodeForModule on the output of (0) to translate LLVM IR to machine code. 2. Figure out the final locations for the code and data generated by MCJIT using an allocator specific to our runtime. Make mapSectionAddress calls to convey this information to MCJIT. 3. Call finalizeObject() to apply reloca...

Hello Lang, I noticed, if I load a obj-File without a main-function, the Jitter won't resolve any address. But if I have a main, everything works fine. Why is this so? Is there a way to stop this? Kind regards Björn Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute. I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules,

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via

...ertions(+), 2 deletions(-) > > diff --git a/lib/ExecutionEngine/MCJIT/MCJIT.cpp b/lib/ExecutionEngine/MCJIT/MCJIT.cpp > index ff8749fbfed..ebe475d9f0b 100644 > --- a/lib/ExecutionEngine/MCJIT/MCJIT.cpp > +++ b/lib/ExecutionEngine/MCJIT/MCJIT.cpp > @@ -222,8 +222,10 @@ void MCJIT::generateCodeForModule(Module *M) { > if (Dyld.hasError()) > report_fatal_error(Dyld.getErrorString()); > > - NotifyObjectEmitted(*LoadedObject.get(), *L); > - > + // Can't call notifiers yet as relocations have not yet been performed, and > + // memory hasn't been marked executa...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien