>> Are jitted binary codes position independent?
>
> We have not found a way to do this, even when creating a TargetMachine with
PIC_, but perhaps we're missing some trick.
I recently added support for the PIC relocation model for x86_64-based ELF
binaries. We also support PIC for MachO. Some other architectures for ELF do
not yet work with PIC relocations.
However, I feel it's worth qualifying this claim by saying that PIC in this
case means that the loader (in this case MCJIT's RuntimeDyld component) can
put the code in arbitrary locations. This is not the same as saying that the
MCJIT client can move the code after it has been generated. However, see below
on that topic.
>> is there a way to relocate
>
>Haven't figured that out either.
This is possible. There is a state with MCJIT where code has been generated but
not yet prepared for final execution. While the code is in this state, you may
call ExecutionEngine::MapSectonAddress to give MCJIT/RuntimeDyld the address to
which you would like to copy the code and then when relocations are applied to
the code they will be applied as if the code were at that location. Note,
however, that you should not actually copy the code to the new location until
after it has been finalized.
I have made some recent changes to the MCJIT and RTDyldMemoryManager interfaces
to make this process easier. In particular, there is now a method exposed to
trigger code generation without also triggering finalization and now the memory
manager receives notification when a module has been generated and loaded into
memory but before the object code is finalized. This is intended as a place to
allow custom memory managers to remap section addresses for the module.
You can find an example of how to do this in the lli tool, which has an option
to inject generated code into an external process. The lli RemoteMemoryManager
will be of particular interest.
>> If the solution requires custom implementation of JITMemoryManager: is
>> there a way to get exact (or sufficient) memory size for binary code
>> before the actual code generation?
>
> The MCJIT makes calls to various allocate*() methods of
SectionMemoryManager
> with exact sizes specified before writing out the code and data sections.
> This is a distinct advantage over the legacy JIT.
To clarify, MCJIT actually creates a single ObjectBufferStream into which the
code is generated and the buffer grows as needed during the code generation
process. The allocate*() methods are called to allocate space for individual
sections as the generated code is copied from the generated object image into
memory allocated by the memory manager.
-Andy
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Caldarale, Charles R
Sent: Wednesday, October 16, 2013 7:57 PM
To: Mikhail Lyapunov; llvmdev at cs.uiuc.edu
Cc: Yuri Dotsenko
Subject: Re: [LLVMdev] Multiple modules JITting
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Mikhail Lyapunov
> Subject: [LLVMdev] Multiple modules JITting
> We're looking for a way to use LLVM to JIT many modules, assuming that
> the full list of modules and their content are not available at a time
> when some of jitted pieces are already in use.
We do this in our project, using MCJIT.
> Is it feasible to destruct ExecutionEngine but keep jitted code alive?
Yes; we use our own memory manager, extending SectionMemoryManager (not
JITMemoryManager). An instance of the memory manager is created and destroyed
with each ExecutionEngine, so we use it as a wrapper for our actual allocation
mechanism; this allows the code/data lifetime to be managed independently of the
ExecutionEngine and Module.
> Are jitted binary codes position independent?
We have not found a way to do this, even when creating a TargetMachine with
PIC_, but perhaps we're missing some trick.
> is there a way to relocate
Haven't figured that out either.
> If the solution requires custom implementation of JITMemoryManager: is
> there a way to get exact (or sufficient) memory size for binary code
> before the actual code generation?
The MCJIT makes calls to various allocate*() methods of SectionMemoryManager
with exact sizes specified before writing out the code and data sections. This
is a distinct advantage over the legacy JIT.
- Chuck
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev