mcbarton wrote: > This is quite a tricky area... > > On Windows, EmulatedTLS _is_ disabled by default, both in MSVC targets and > MinGW targets. However, for interop with (GCC's) libstdc++ (which currently > exposes TLS symbols in the public ABI), users may need to enable emulated TLS > if linking against that. Clang in the msys2 distribution is patched to enable > emulated TLS by default, in the environments that default to using libstdc++. > > However do note that this status quo may change soon; GCC will possibly get > support for native TLS soon, > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881, and as part of that, the > use of direct access to TLS variables across the libstdc++ ABI boundary also > will need to be fixed. (Because with native TLS, it's not possible to > directly access a TLS variable defined in a different DLL.) > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670508.html is a > patch that will do this; apparently it's not merged yet, but it will be > needed by the native TLS support in GCC. > > So, soon one may not need to enable emulated TLS at all in these > environments, and the need for this patch should go away. > > But before that, if you're in an environment that _does_ default to emulated > TLS, that's done for a reason; disabling it like this will break use of other > parts from libstdc++ that involve TLS objects. > > So in general, if the environment is set up to require emulated TLS, we can't > just override that as it will have consequences. The correct solution would > be to make sure that the emulated TLS helper routines are available to link > in for the JIT; they're provided by libgcc or compiler-rt builtins. Exactly > how that's usually done within JIT/clang-repl, I'm not really familiar with. > But it's the same situation as if you're compiling code that generates a call > to any other compiler helper function from libgcc/compiler-rt builtins. > > That said, as emulated TLS is disabled by default for all Windows targets in > upstream LLVM, this change should in itself mostly be a no-op. > > Not sure what the practice is wrt tests etc for changes like this?
@mstorsjo now that gcc 16 has native tls support on Windows does that mean if compiling with gcc16 onwards llvm should be able to support native tls on Windows? Sorry in advance if its a stupid question. https://github.com/llvm/llvm-project/pull/127468 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
