[LLVMdev] Dynamically loading native code generated from LLVM IR

Armin Steinhoff as at steinhoff-automation.com
Fri Oct 12 05:35:56 PDT 2012


Tim Northover wrote:
> Hi Baris,
>
>> If I could produce a .so file in step 1, my problem would be solved. llc has a "-relocation-model=pic" option, but the file produced with that did not dynamically load.
> That relocation-model=pic option usually necessary for a linker to be
> able to produce a .so file (it changes how variables are addressed so
> that more things can be decided when the .so is loaded), but it won't
> produce a .so itself.
>
>> So, my question is: Which API should I look at to emit dynamically loadable native code from LLVM IR?
> The JIT sounds like it does almost exactly what you want. LLVM's JIT
> isn't a classical lightweight, dynamic one like you'd see for
> JavaScript or Java. All it really does is produce a native .o file in
> memory, take care of the relocations for you and then jump into it (or
> provide you with a function-pointer).

OK ... I have a similar issue. What happens if the code located in the 
.o file has references to external libs ?
How can I link the inmemory .o file against the external libs ... just 
to get a fully executable code segment in memory.

Best Regards

Armin Steinhoff

http://www.steinhoff-automation.com

> Is there any other reason you
> want to avoid it?
>
> Otherwise, only a full linker is capable of turning a .o into
> something loadable with "dlopen" or its equivalents. That's a lot of
> work, though I suppose you could fork a process to the system's linker
> if there is one.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list