================
@@ -388,6 +395,23 @@
IncrementalExecutorBuilder::create(llvm::orc::ThreadSafeContext &TSC,
if (!JB)
return JB.takeError();
JITBuilder = std::move(*JB);
+#ifdef __APPLE__
+ // On Darwin, thread_locals are lowered to emulated TLS, but the runtime
+ // (__emutls_get_address) lives in the compiler-rt builtins archive and
+ // nothing else in this process references it, so it isn't linked in and
+ // process-symbol lookup cannot find it. Taking its address here forces
+ // the archive member into the binary; defining it as an absolute symbol
+ // makes it visible to JIT'd code. In-process execution only: the address
+ // is meaningless in an out-of-process executor.
+ JITBuilder->setNotifyCreatedCallback([](llvm::orc::LLJIT &J) {
+ auto &JD = J.getProcessSymbolsJITDylib() ? *J.getProcessSymbolsJITDylib()
+ : J.getMainJITDylib();
+ return JD.define(llvm::orc::absoluteSymbols(
+ {{J.mangleAndIntern("__emutls_get_address"),
+ {llvm::orc::ExecutorAddr::fromPtr(&__emutls_get_address),
+ llvm::JITSymbolFlags::Exported}}}));
+ });
+#endif
----------------
conrade-ctc wrote:
Done — the JIT-side logic now keys on the triple (`TT.isOSBinFormatMachO()`) at
runtime, so retargeting is unaffected. One small `#ifdef __APPLE__` remains,
reduced to a host-capability accessor (`getEmuTLSGetAddressPtr`) for the extern
reference itself: an unconditional strong reference to `__emutls_get_address`
would fail to link on MSVC (no emulated-TLS runtime exists there, see #187040),
and a weak reference would not trigger archive-member extraction on Darwin,
defeating the force-link. On non-Apple hosts the accessor returns null and
folds away entirely (verified: zero emutls references in the Linux object).
https://github.com/llvm/llvm-project/pull/208413
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
