[PATCH] MCJIT::clearSymbolAddress

Kaylor, Andrew andrew.kaylor at intel.com
Fri Oct 18 10:46:03 PDT 2013


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/2014059c/attachment.html>


More information about the llvm-commits mailing list