[clang] [clang-repl] Disable EmulatedTLS on Windows for interpreter executor (PR #127468)

[Martin Storsjö via cfe-commits]

mstorsjo 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?

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