[llvm-dev] ORC JIT Weekly #16 -- JITLink ELF/x86-64 review, more removable code updates

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Sat May 16 21:31:08 PDT 2020

Hi All,

Jared Wyles has posted a initial implementation of JITLink for ELF/x86-64
at https://reviews.llvm.org/D79832. It is currently missing relocation
support, but can already execute simple ELF objects. I am very excited to
see an ELF JITLink implementation under development: once complete it will
make a lot of ORC features and improvements that are currently Darwin only
available on other platforms, especially Linux. Thanks very much Jared!

Removable code support is proving to be a deeper rabbit hole than I
expected. The fix in 41379f1ec46, sharing JITDylib ownership between
ExecutionSession and MaterializationResponsibility, leaves too many clients
(e.g. JITDylibSearchOrders, ReExportsMaterializationUnit) holding
potentially dangling JITDylib references. Unfortunately we cannot simply
switch to holding shared_ptr<JITDylib>s everywhere either: As things stand
that would introduce ownership cycles, and even if these cycles were
removed it would be difficult to guard against new ones being reintroduced.
I think the solution will be to break the JITDylib class up, at least
internally, into a facade (JITDylib) and actual implementation
(JITDylibImpl). The JITDylib facade will not own anything, but will
guarantee clean failure if any operations are attempted after the JITDylib
is closed. The JITDylibImpl *will* be able to own other objects and will be
uniquely owned by the ExecutionSession. This will have the additional
advantage of moving a lot of implementation gunk out of the Core.h header.

I may have to set the removable code work aside for a week or two to deal
with some other bug fixes and feature work, but hope to get back to it
soon: Once removable code lands (and the docs and tutorials are updated) we
will finally be in a position to remove OrcV1.

-- Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200516/a073ba7c/attachment.html>

More information about the llvm-dev mailing list