[clang] [llvm] Reland "[ORC] Track __emutls_t definitions in IRMaterializationUnit" (#207161) (PR #208413)

[Vassil Vassilev via cfe-commits]

================
@@ -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
----------------
vgvassilev wrote:

Can we check the target triple information rather than fixing this at compile time? That would hinder retargetting...

https://github.com/llvm/llvm-project/pull/208413