[LLVMdev] Dynamic (JIT) type resolution
cr88192 at hotmail.com
Tue Nov 6 17:01:59 PST 2007
----- Original Message -----
From: "Nicolas Geoffray" <nicolas.geoffray at lip6.fr>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Wednesday, November 07, 2007 10:03 AM
Subject: Re: [LLVMdev] Dynamic (JIT) type resolution
> BGB wrote:
>> maybe a tradeoff is possible:
>> the function to get the offset is replaced by a function pointer and a
>> (avoiding many of the general problems involved with using
> For me there are no problems of self-modifying code (the LLVM jit
> already does it)
there are, 'further' problems, than simply having a JIT generate the code...
>> the fist time it is called, the function pointer points to 'stub A',
>> calls the function to lookup the slot offset,
>> this function then stores the value in a variable, and updates the
>> pointer to point to 'stub B'.
>> 'stub B', simply returns the value stored in the variable.
> That's again what I want to avoid. This is my current implementation,
> and I _really_ would like to avoid unnecessary calls once the type is
ok, here is another option then:
the stub is set up to manually modify the code near the return address (may
be arch specific and require spiffy use of assembler).
an example is this (assuming x86):
for the stub, as opposed to executing a 'ret', you have something like this
in its place:
mov byte [edx-5], 0xB8 ;mov eax, imm32
mov dword [edx-4], eax ;store return value in imm
this will replace the 'call' instruction generating the call with a mov,
thus further runs will not invoke a call (note, be very sure this stub is
only ever called with a 'call' instruction).
(in LLVM, though I am not certain as I don't know much of the internals,
this could require either tweaking the codegen, or hand-crafted stub
now, how you would go about implementing this is up to you.
More information about the llvm-dev