[PATCH] MCJIT::clearSymbolAddress

[Yaron Keren]

Hi Andy,

Everything you write is correct. This is not enough. It's part of the API
required a complete solution.

If function replacement is not possible for a compiled module, given this
API and a relink function, a solution could be a smart function replacer:

If the function signature is the same, the usual case, hide/replace the old
function, recompile it and relink all callers to the new function.

If the function signature changed, hide/replace/recompile the function and
its callers (possibly in a new module hiding the old copies) and relink the
callers-callers to the new callers.

This does leak memory of the hidden compiled functions we're replacing.

If we can mange this I think that the transition from the old JIT would be
much easier.

Yaron




2013/10/18 Kaylor, Andrew <andrew.kaylor at intel.com>

>  This is a potentially tricky case.  Let me give you a hypothetical
> scenario:****
>
> ** **
>
> Module A contains a function FA.****
>
> Modules B and C contain functions (FB and FC) that call FA.****
>
> Module D contains a new definition of FA.****
>
> ** **
>
> Now suppose I add modules A, B and C to MCJIT and make a call to FB.  This
> will generate code for modules A and B and link module B to module A’s
> definition of FA.  Then suppose I call your new function to clear the FA
> symbol and add module D to MCJIT.  Now if I call FC, MCJIT will generate
> code for modules C and D and link FC to module D’s definition of FA.
> However, module B will still be linked to module A’s definition of FA.****
>
> ** **
>
> To complicate things even further, if there were some unrelated function
> in module B that required another unrelated function in module C then FC
> will be bound to module A’s FA when FB is called, though that might not be
> obvious to the user.  Even worse, if FC calls FB and FA then it would be
> possible to have FC linked to module A’s FA through FB and to module D’s FA
> through its direct call.****
>
> ** **
>
> That’s not to say that we don’t need to address your use case.  I just
> don’t think the simple solution is enough.****
>
> ** **
>
> -Andy****
>
> ** **
>
> *From:* Yaron Keren [mailto:yaron.keren at gmail.com]
> *Sent:* Friday, October 18, 2013 4:39 AM
> *To:* llvm-commits at cs.uiuc.edu; Kaylor, Andrew
> *Subject:* [PATCH] MCJIT::clearSymbolAddress****
>
> ** **
>
> The use-case is replacing a named function before creating a same-named
> function in a new module, such as in REPL.****
>
> ** **
>
> With the older JIT a function could be removed from the symbol table (and
> memory freed) by calling freeMachineCodeForFunction. ****
>
> ** **
>
> The new MCJIT does not implement this function - may be impossible to
> modify the object - so the next best thing is to remove the symbol from the
> symbol table so the older copy will not be found anymore and then a new
> function could be created.****
>
> ** **
>
> Since MCJIT uses GlobalSymbolTable in RuntimeDyldImpl.h rather than
> the GlobalAddressMap in ExecutionEngineState (could EEState be reused by
> MCJIT somehow?) the code is MCJIT specific.****
>
> ** **
>
> To expose it to the programmer the function appears in EE as well with a
> comment and the call chain is****
>
> ** **
>
> EE->MCJIT->RuntimeDyld->RuntimeDyldImpl->GlobalSymbolTable.erase().****
>
> ** **
>
> Yaron****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131018/f2029620/attachment.html>