[LLVMdev] Can LLVM jitter emit the native code in continuous memory addresses ?

[Mohammed Ag]

Suppose that i have may own implementation for the JITMemoryManager which
takes care of that the allocated chunks of memory to be continus.
So i don't understand is the generated JIT code is position-independed ? or
at least can i obligue the jitter to emit PIC code only with something
like options flag ?
On Mon, Jun 27, 2011 at 7:48 AM, Reid Kleckner <reid.kleckner at gmail.com>wrote:

> It is possible to subclass JITMemoryManager and pass in a custom memory
> manager, but I don't believe you'll be able to convince the JIT to emit PIC
> code without hacking on LLVM a bit.
>
> Reid
>
>   On Sun, Jun 26, 2011 at 4:21 AM, Mohammed Ag <admirer4 at gmail.com> wrote:
>
>>      **
>>
>> I have question relating to LLVM Jitter: Can i obligue the LLVM Jitter to
>> emit the native code in continuous memory addresses ? and to be PIC ? what i
>> want to do is to move the JIT code to another process in order to execute
>> it, my approach is to save the JIT code in buffer i will save it to file and
>> pass it to the execution process.
>>
>> what i mean by "load" is to simply read the bits from file into buffer i
>> don't want to generate elf or something like this.
>>
>> Here's an example: suppose i have C source file which contain:
>>
>> Global variables
>> ----------------
>> Function Foo()
>> ----------------
>> Function Too()
>>
>> when i request the JIT code i want the JIT to be in continuous memory
>> addresses (with 4-bytes aligment):
>>
>> 0x100: Global Vars (take 16 Byte)
>> 0x110: Foo() Code (take 32 Byte)
>> 0x130: Too() Code (take 32 Byte)
>> 0x150: end.
>>
>> So i can save the JIT code (form 0x100 -> 0x150) and i can load it in the execution process in any virtual address,
>> assume (0x300 -> 0x350) and execute it by jump to the ep.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110627/f73eeba5/attachment.html>