3 ms·

It used to be that .dlls loaded by the .exe on startup (e.g. implicitly listed there) would get their thread local vars correctly (TLS), but dlls loaded later (

by malkia 2y ago

It used to be that .dlls loaded by the .exe on startup (e.g. implicitly listed there) would get their thread local vars correctly (TLS), but dlls loaded later (like /DELAYLOAD or through LoadLibrary) would not. (the workaround was to initialize these through TlsAlloc/TlsFree, and have hook in DllMain to clean up) But then Microsoft added /Zc:tlsGuards - https://learn.microsoft.com/en-us/cpp/build/reference/zc-tlsguards?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/zc-tls... - which is now the default that fixes the issue, but with some significant performance penalty (e.g. the "bug" that I've listed). I guess you can't have it both ways easy... On the clang/clang-cl side, there is https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fms-tls-guards https://clang.llvm.org/docs/ClangCommandLineReference.html#c... to support this. So check your compiler version and options :) Also the notes posted here about CRT mixing might apply to you (not sure though) - https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-... I work in a gamedev world, and plugins, ffi, delay loaded dlls etc. are constant pain that one needs to look and solve issues around.

spacechild1 2y ago
So this was only a MSVC bug? Most people compile Pd with MinGW, which would explain why we never ran into this issue. Do you happen to have a link to the original MSVC bug report (i.e. the wrong thread locals, not the performance regression)?
- legobmw99 2y ago
  Note that MinGW uses libwinpthread, which is known to have slow TLS behavior anyway (I've observed a 100% overhead compared to running the same program under WSL using a linux-native GCC). c.f. https://github.com/msys2/MINGW-packages/discussions/13259 https://github.com/msys2/MINGW-packages/discussions/13259
- malkia 2y ago
  I haven't looked into it, but going through the release notes for tlsGuards showed this - though not directly a bug report https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#tls-guard-changes https://learn.microsoft.com/en-us/cpp/overview/cpp-conforman... and also the implementation in "clang" (for "clang-cl" being conformant with MSVC) - https://reviews.llvm.org/D115456#3217595 https://reviews.llvm.org/D115456#3217595 then last year clang-cl also added ways to disable this (if need to), probably this hit some internal issue and had to be resolved. Maybe "thread_local" have become more widely used (unlike OS specific "TlsAlloc")
  - spacechild1 2y ago
    Thanks! Fortunately, this issue does not affect us because our thread locals are all zero initialized integers or pointers.

by malkia 2y ago

spacechild1 2y ago

So this was only a MSVC bug? Most people compile Pd with MinGW, which would explain why we never ran into this issue. Do you happen to have a link to the original MSVC bug report (i.e. the wrong thread locals, not the performance regression)?

legobmw99 2y ago
Note that MinGW uses libwinpthread, which is known to have slow TLS behavior anyway (I've observed a 100% overhead compared to running the same program under WSL using a linux-native GCC). c.f. https://github.com/msys2/MINGW-packages/discussions/13259 https://github.com/msys2/MINGW-packages/discussions/13259
malkia 2y ago
I haven't looked into it, but going through the release notes for tlsGuards showed this - though not directly a bug report https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#tls-guard-changes https://learn.microsoft.com/en-us/cpp/overview/cpp-conforman... and also the implementation in "clang" (for "clang-cl" being conformant with MSVC) - https://reviews.llvm.org/D115456#3217595 https://reviews.llvm.org/D115456#3217595 then last year clang-cl also added ways to disable this (if need to), probably this hit some internal issue and had to be resolved. Maybe "thread_local" have become more widely used (unlike OS specific "TlsAlloc")
- spacechild1 2y ago
  Thanks! Fortunately, this issue does not affect us because our thread locals are all zero initialized integers or pointers.