[llvm-dev] Loading object files into the JIT and forcing them to link without symbol lookup.

Christian Schafmeister via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 7 10:13:00 PST 2020


Lets say I add an ObjectFile as in RTDyldObjectLinkingLayer->add(object_file).    Is there a way to force the runtime linker to link the ObjectFile?We are implementing Clasp, a Common Lisp that uses llvm as the backend.   I'm exploring loading object files and linking them at runtime rather than linking them into dynamic libraries and loading those into our system (we currently do this).I'm using the new ORCV2 JIT and I've cobbled together a JIT by following Lang Hame's talk at the 2018 LLVM dev meeting.I can add object files to the linking layer - but I need to lookup a symbol in the object file to get it to link.The problem is, Common Lisp is a dynamic language.  We may end up loading the object file repeatedly.I currently need to lookup a symbol to get it to link so that I can execute any code.But if I use a fixed symbol - then I can only load the object file once because after that I get a symbol clash.
Alternatively - is there a symbol linkage that will let me reload the object file repeatedly and look up the address of the symbol in the new object file?I've tried linkonce_odr - but that works once and then gives me the address of the first symbol that was loaded, bypassing the linking of the object file.I looked into the RTDyldObjectLinkingLayer code and RTDyldObjectLinkingLayer::runOutstandingMUs() appears to be what I want - but it is a 'private' function in the RTDyldObjectLinkingLayer class and it looks like it's marked for deprecation.
So - how do I get the linking effect of looking up a symbol without looking up a symbol?Or how do I declare a symbol that I can lookup when I load ObjectFiles repeatedly.


Christian Schafmeister
chris.schaf at verizon.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200107/8d5f8b64/attachment.html>


More information about the llvm-dev mailing list