<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>Jared Wyles has posted a initial implementation of JITLink for ELF/x86-64 at <a href="https://reviews.llvm.org/D79832">https://reviews.llvm.org/D79832</a>. 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!</div><div><br></div><div>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 <i>will</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>-- Lang. </div></div></div></div>