search for: emitobject

Hello all, I'm trying to hack MCJIT::emitObject to optionally output the corresponding text assembly associated with the object code being emitted (if a debug flag is set in the app/dev environment which is hosting LLVM). I attempted to do this by adding another AsmPrinter pass to the PassManager, but this runs into all sorts of problems because...

...g on-the-fly with MCJIT on an ARM Pandaboard. Viewer discretion is advised! https://vimeo.com/60407237 Here is the overview of changes I promised a couple of weeks back. These comments are based on the 3.3 trunk of about 3 weeks ago. -- RuntimeDyld -- Relocations needs to be cleared between each emitObject. New method required: clearRelocations void RuntimeDyldImpl::clearRelocations() { ExternalSymbolRelocations.clear(); Relocations.clear(); } void RuntimeDyld::clearRelocations() { Dyld->clearRelocations(); } -- RuntimeDyldImpl -- void clearRelocations(); -- SectionMemoryManager --...

...294119968 [ 3149s] 11 libLLVMCore.so 0x00003fff7f35c9d8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 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...

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just

...7f35c9d8 > > llvm::legacy::PassManagerImpl::run(llvm::Module&) + 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...

...cpp > > I'm not sure how efficient the disassembling is, but at least the process is > pretty self-contained. > > > On Tue, Jun 24, 2014 at 1:33 PM, Craig Smith <craig at ni.com> wrote: >> >> >> Hello all, >> >> I'm trying to hack MCJIT::emitObject to optionally output the >> corresponding text assembly associated with the object code being emitted >> (if a debug flag is set in the app/dev environment which is hosting LLVM). >> I attempted to do this by adding another AsmPrinter pass to the >> PassManager, but this run...

...ld need to be updated with the reserveAllocationSpace signature change (though they could just ignore the new parameter). 4. We could avoid needing to crack the object file for this information altogether; MCJit could add a hook where a client could insert passes into the PassManager used in emitObject; LLILC could attach a pass that would consult the MachineModuleInfo, where this information could be stored (it's similar to what's stored in the WinEHFuncInfos hanging off the MMI today). But adding hooks for client passes might be opening a can of worms... My inclination would be #2 or...

....dylib`llvm::legacy::PassManagerImpl::run(this=0x0000000106feb9f0, M=0x0000000106fe6f30) + 544 at LegacyPassManager.cpp:1711 frame #17: 0x000000010108466d 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::getFunctionAddres...

...ld need to be updated with the reserveAllocationSpace signature change (though they could just ignore the new parameter). 4. We could avoid needing to crack the object file for this information altogether; MCJit could add a hook where a client could insert passes into the PassManager used in emitObject; LLILC could attach a pass that would consult the MachineModuleInfo, where this information could be stored (it's similar to what's stored in the WinEHFuncInfos hanging off the MMI today). But adding hooks for client passes might be opening a can of worms… My inclination would be #2 or #3...

...agerImpl::run(this=0x0000000106feb9f0, > M=0x0000000106fe6f30) + 544 at LegacyPassManager.cpp:1711 > frame #17: 0x000000010108466d > 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`ll...

...th the reserveAllocationSpace signature change (though they could > just ignore the new parameter). > > 4. We could avoid needing to crack the object file for this > information altogether; MCJit could add a hook where a client could insert > passes into the PassManager used in emitObject; LLILC could attach a pass > that would consult the MachineModuleInfo, where this information could be > stored (it's similar to what's stored in the WinEHFuncInfos hanging off the > MMI today). But adding hooks for client passes might be opening a can of > worms… > > &gt...

...s RuntimeDyld to load them. If you had a hook to save the generated object, you could use RuntimeDyld directly to load it later. There are other ways to generate the object image (i.e. without MCJIT), but I'm not sure it would be easier. You basically just need to grab the Buffer that MCJIT::emitObject() has after it calls PM.run() and Buffer->flush() but before it passes it to Dyld.loadObject(). If you prefer, you could copy what MCJIT does and move it somewhere in your own code. There's not a lot to it. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:l...

...agerImpl::run(this=0x0000000106feb9f0, > M=0x0000000106fe6f30) + 544 at LegacyPassManager.cpp:1711 > frame #17: 0x000000010108466d > 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`ll...

The pass manager is re-created in emitObject on every call. Andy, is that needed or can we create the PM in MCJIT constructor and keep it around? Yaron 2013/11/19 Kevin Modzelewski <kmod at dropbox.com> > So I finally took the plunge and switched to MCJIT (wasn't too bad, as > long as you remember to call InitializeNati...

...ld need to be updated with the reserveAllocationSpace signature change (though they could just ignore the new parameter). 4. We could avoid needing to crack the object file for this information altogether; MCJit could add a hook where a client could insert passes into the PassManager used in emitObject; LLILC could attach a pass that would consult the MachineModuleInfo, where this information could be stored (it's similar to what's stored in the WinEHFuncInfos hanging off the MMI today). But adding hooks for client passes might be opening a can of worms… My inclination would be #2 or #3...

...ld need to be updated with the reserveAllocationSpace signature change (though they could just ignore the new parameter). 4. We could avoid needing to crack the object file for this information altogether; MCJit could add a hook where a client could insert passes into the PassManager used in emitObject; LLILC could attach a pass that would consult the MachineModuleInfo, where this information could be stored (it's similar to what's stored in the WinEHFuncInfos hanging off the MMI today). But adding hooks for client passes might be opening a can of worms… My inclination would be #2 or #3...

So I finally took the plunge and switched to MCJIT (wasn't too bad, as long as you remember to call InitializeNativeTargetDisassembler if you want disassembly...), and I got the functionality to a point I was happy with so I wanted to test perf of the system. I created a simple benchmark and I'd thought I'd share the results, both because I know I personally had no idea what the

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

...ld need to be updated with the reserveAllocationSpace signature change (though they could just ignore the new parameter). 4. We could avoid needing to crack the object file for this information altogether; MCJit could add a hook where a client could insert passes into the PassManager used in emitObject; LLILC could attach a pass that would consult the MachineModuleInfo, where this information could be stored (it's similar to what's stored in the WinEHFuncInfos hanging off the MMI today). But adding hooks for client passes might be opening a can of worms… My inclination would be #2 or #3...

...yld to load them. If you had a hook to save the generated object, you could use RuntimeDyld directly to load it later. There are other ways to generate the object image (i.e. without MCJIT), but I'm not sure it would be easier. > > You basically just need to grab the Buffer that MCJIT::emitObject() has after it calls PM.run() and Buffer->flush() but before it passes it to Dyld.loadObject(). If you prefer, you could copy what MCJIT does and move it somewhere in your own code. There's not a lot to it. > > -Andy > > > -----Original Message----- > From: llvmdev-bo...