[LLVMdev] jit code linkage at run time

Kaylor, Andrew andrew.kaylor at intel.com
Tue Oct 1 14:41:57 PDT 2013


External symbol resolution is handled by the memory manager.  The default memory manager used with the JIT execution engine uses sys::DynamicLibrary::SearchForAddressOfSymbol to look for symbols, and that's how it's finding 'pow' in your case.  On Windows that ends up with a call to GetProcAddress for each loaded library and you get whichever one happens to be found first.

To link to a specific implementation of the symbol, you'll need to provide a custom memory manager.  You can create a memory manager that aggregates the default memory manager (created via JITMemoryManager::CreateDefaultMemManager()) and defers everything except getPointerToNamedFunction to the default memory manager.  Then your custom implementation of getPointerToNamedFunction can provide the address of whichever pow function you prefer.

Note that if you ever switch over to the MCJIT execution engine you'll find that it behaves just like this except that you'll want a different default memory manager as your base.

-Andy

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Peng Cheng
Sent: Tuesday, October 01, 2013 2:16 PM
To: LLVMdev at cs.uiuc.edu
Subject: [LLVMdev] jit code linkage at run time

Hi,

I am using llvm to generate jit code for numerical computation on window 7 64 platform.  There is a function call, pow, in the jit code.  The problem is that at run time, the pow function call sometimes links to msvcrt.dll, and sometimes to msvcr100.dll.  These two calls from two dlls return different results, causing sporadic results.

I tried to make the pow function either intrinsic or function call.  Both did not work.

My question is that:

Is there a way to tell the jit engine to link the pow function to a specific dll?

or

are there any other suggestions?

Thanks,
-Peng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131001/dd315a5f/attachment.html>


More information about the llvm-dev mailing list