search for: linkingmemorymanager

...d::string &Name, bool > AbortOnFailure). So, the hypercall resolution can be done here. > > In MCJIT, during finalizeObject(), all the symbol relocations are > finalized. In the Memory Managers, the external symbols are resolved. So, > the hypercall resolution can be done in > LinkingMemoryManager::getSymbolAddress(). > > > > In JIT::getPointerToNamedFunction(), check whether the function name is > PerformCustomCallback and store the address of the function > PerformCustomCallback in the global table. So the next time a call happens, > JIT will get the address directly f...

...interToNamedFunction(const std::string &Name, bool AbortOnFailure). So, the hypercall resolution can be done here. In MCJIT, during finalizeObject(), all the symbol relocations are finalized. In the Memory Managers, the external symbols are resolved. So, the hypercall resolution can be done in LinkingMemoryManager::getSymbolAddress(). In JIT::getPointerToNamedFunction(), check whether the function name is PerformCustomCallback and store the address of the function PerformCustomCallback in the global table. So the next time a call happens, JIT will get the address directly from the table. In MCJIT, in L...

...ointerToNamedFunction(const std::string &Name, bool AbortOnFailure). So, the hypercall resolution can be done here. In MCJIT, during finalizeObject(), all the symbol relocations are finalized. In the Memory Managers, the external symbols are resolved. So, the hypercall resolution can be done in LinkingMemoryManager::getSymbolAddress(). In JIT::getPointerToNamedFunction(), check whether the function name is PerformCustomCallback and store the address of the function PerformCustomCallback in the global table. So the next time a call happens, JIT will get the address directly from the table. In MCJIT, in Linki...

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options

Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!