llvm dev - Jun 2007 - [LLVMdev] on-the-fly recompilation/relinking

Hi

Assuming I had an application stub based on (say) lli, and I'd like to allow
a hypothetical IDE to recompile and relink a function:

Is that supported in any way currently? Assuming actually patching all call
sites to point to the newly generated function is possible, I guess what I
need is to be able to either track or find all of the call sites. The
trickiest bit seems to be if the function that's being redefined has been
inlined. Ideally, I'd then (recursively) recompile/relink the function that
it was inlined into given the new definition, but I guess I could just error
out, or perhaps more simply, disable all inlining optimization in the first
place.

A secondary goal (less important) would be to able to "free" the then
unused
function in some way, but I'm happy to ignore that problem for now.

Is anyone doing this currently? Any suggestions of where to start on that?
Is this even vaguely do-able or am I overlooking large problems?

thanks,
scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070623/8c5a532c/attachment.html>

On Sat, 23 Jun 2007, Scott Graham wrote:
> Assuming I had an application stub based on (say) lli, and I'd like to
allow
> a hypothetical IDE to recompile and relink a function:
ok
> Is that supported in any way currently? Assuming actually patching all call
> sites to point to the newly generated function is possible, I guess what I
> need is to be able to either track or find all of the call sites.
The JIT directly supports this at the function granularity, just call 
ExecutionEngine::recompileAndRelinkFunction(F)
> The trickiest bit seems to be if the function that's being redefined
has
> been inlined. Ideally, I'd then (recursively) recompile/relink the 
> function that it was inlined into given the new definition, but I guess 
> I could just error out, or perhaps more simply, disable all inlining 
> optimization in the first place.
Yep, either solution would work.
> A secondary goal (less important) would be to able to "free" the
then unused
> function in some way, but I'm happy to ignore that problem for now.
ExecutionEngine::freeMachineCodeForFunction does this

However, the way recompileAndRelinkFunction works is to insert an 
unconditional branch at the start of the function to the newly compiled 
code, so you can't free the old function in this case.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/