search for: symbolresolver

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

...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 only moment I can do this is in "notifyObjectLoaded&q...

...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 MCJIT and ORC) will now search for symbols using the SymbolResolver's findSymbolInLogicalDylib first, before falling back to the findSymbol method if findSymbolInLogicalDylib returns a null result. This is a step towards making RuntimeDyld behave more like a static linker: we prefer to link against symbols defined in the same "logical dylib" as the m...

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

...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 only moment I can do this is in "notifyObjectLoaded&...

...tructions, as described in pseudocode: Before: declare b(...) define a(): { ... call b(%1, %2, %3) ... } After: @b_trampoline = <pointer to b()> declare b(...) define a(): { ... %ptr = load @b_trampoline call %ptr(%1, %2, %3) ... } Then, when you load module A SymbolResolver will ask for an address of b_trampoline, you can give back an address of a heap-allocated storage, i.e.: ... uint64_t *trampolineStorage = new uint64_t; ... SymbolResolver::findSymbol(const std::string &name) { if (name == "b_trampoline") { JITSymbolInfo((uint64_t) tramp...

...kely 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 MCJIT and ORC) will now search > for symbols using the SymbolResolver's findSymbolInLogicalDylib first, > before falling back to the findSymbol method if > findSymbolInLogicalDylib returns a null result. > > This is a step towards making RuntimeDyld behave more like a static > linker: we prefer to link against symbols defined in the same "logi...

...really interested into this subject. In my current use case I have two BC files which have cross references to each other, normally I could just add them both to the llvm::ExecutionEngine and they will be resolved. But I would like to resolve these cross references by myself, through the llvm::JITSymbolResolver but I see no way for this, since both files references each other. If I jit A, it will reach the undefined function from file B. So at this point I would have to jit B, but B references a function from A, which isn't completely resolved yet. Is there a way to get the addresses of the functions...

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

...ertion `use_empty() && "Uses remain when a value is destroyed!"' failed. As a separate but probably related detail, the function 'invoke foo' is not being inserted in the foo2 IR. The foo2 invoke generation looks like this: llvm::Module* module = Compiler::Services::SymbolResolver::getInstance()->resolveOrCreateModule( buildParameters.getLLVMContext() , buildParameters.getModuleDefinition() ); HAssertMsg( 0 != module , " null module "); llvm::Module* excptModule = Compiler::Services::SymbolResolver::getInstance()-&...

...d when I designed Orc, so they raise some interesting design questions which I don't have good answers to yet. (E.g. The interface for the Orc layer concept assumes that there's a RuntimeDyld instance embedded at the bottom of the stack. That's why addModuleSet takes a MemoryManager and SymbolResolver. If there's no RuntimeDyld instance at the bottom of the stack, it's not obvious that the interface should require those). For now I recommend just creating a local copy of the ObjectLinkingLayer and removing the call to resolveRelocations. I'll keep thinking about the best way to supp...

...cate whether relocation resolution should be performed. Would you be ok with such a change? Thanks, Eugene template <typename NotifyLoadedFtor = DoNothingOnNotifyLoaded> class ObjectLinkingLayer : public ObjectLinkingLayerBase { private: template <typename MemoryManagerPtrT, typename SymbolResolverPtrT> class ConcreteLinkedObjectSet : public LinkedObjectSet { public: ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr, SymbolResolverPtrT Resolver) : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), Resolver(std::move(Resolver)) {...

...ooOpt = jit_recompile_hot(&foo); fooOpt(); } // foo body } You would implement the jit_recompile_hot function yourself in your JIT and make it available to JIT'd code via the SymbolResolver. When the trigger condition is met you'll get a call to recompile foo, at which point you: (1) Add the IR for foo to a 2nd IRCompileLayer that has been configured with a higher optimization level, (2) look up the address of the optimized version of foo, and (3) update the function pointer for f...

...eferences with own addresses? Like when somebody used printf in the > generated obj-File, but I replace the address with my own printf? > > You can load precompiled object files by calling addObjectSet on the > ObjectLayer. > > All external symbol references are resolved by the JITSymbolResolver that > is created by createLambdaResolver. In your example the resolution process > is two-step: First the JIT searches its own function definitions to see if > there is a function called "printf" defined there (this is what the call to > CompileLayer.findSymbol does): > &g...

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