TSan on Windows?

Hello all,

Clang(-cl) on windows has matured well over the last couple of years.
A long time ago, I’ve started making our code base compatible with clang-cl, at a time that try and throw where not yet supported for this platform.

Since that point, I’ve logged several bugs, did way too many commits on our code and upgraded clang executables several times.
With the first executables actually being able to run (in full debug builds), a world of opportunities is available.
I was positively surprised to see UBSAN work out-of-the box. (given some false positives in non-standard code, which I still have to fix)

Unfortunately, TSAN ain’t supported as indicated on https://clang.llvm.org/docs/ThreadSanitizer.html and gives a compilation error when you try it.

Are their active plans to get this activated on Windows in the near future?

If not, would it be feasible for a newbie in llvm-code to look at this?

Happy new year!

I don’t think there are any plans to pursue it in the near future, and I estimate that it would be quite a lot of work to make it work for C/C++. I wouldn’t recommend that a newbie take this on, as we’ve discovered that Windows ASan has an enormous maintenance cost.

I believe Dmitry Vyukov got TSan working on Windows with GCC and Mingw for Go, but I’ve never compiled it or tried to use it. A large portion of the complexity in ASan comes from fighting with the various MSVC CRTs (static/dynamic, plus every new version) to intercept heap allocation and key string functions like memset, strlen, etc. This matters a lot when looking for races in C/C++ programs, but if you are looking for races in Go, then these things either aren’t necessary, or are greatly simplified by committing to static linking with the Mingw CRT.

I don't think there are any plans to pursue it in the near future, and I estimate that it would be quite a lot of work to make it work for C/C++. I wouldn't recommend that a newbie take this on, as we've discovered that Windows ASan has an enormous maintenance cost.

I believe Dmitry Vyukov got TSan working on Windows with GCC and Mingw for Go, but I've never compiled it or tried to use it. A large portion of the complexity in ASan comes from fighting with the various MSVC CRTs (static/dynamic, plus every new version) to intercept heap allocation and key string functions like memset, strlen, etc. This matters a lot when looking for races in C/C++ programs, but if you are looking for races in Go, then these things either aren't necessary, or are greatly simplified by committing to static linking with the Mingw CRT.

Yes, Tsan/Go works on Windows for like 5 years without any major
problems. And, yes, it does not have any interceptors.
I don't know what are unique problems for C/C++. Are these fixes for
C/C++ interceptors will fix both asan and tsan? If so, additional tsan
cost may be not too high.
I guess we won't know until we try.
The first thing would be to figure out working virtual address space
layout in tsan_platform.h.