Hi gcc developers, I wanted to give heads up regarding a significant re-design of the ThreadSanitizer runtime: https://reviews.llvm.org/D112603 Currently it's submitted: https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027 but can well be rolled back if too many buildbots fail, but should be submitted again soon anyway.
It was extensively tested and lots of bugs were fixed, but it's still possible it will cause some issues just because of the size of the change and OS/arch sensitivity. For a wide range of real programs it provides 20%-4x speedup on x86_64 and 20-40% memory consumption reduction. One issue that will come up with gcc is the use of the new disable_sanitizer_instrumentation attribute in tests: https://clang.llvm.org/docs/AttributeReference.html#disable-sanitizer-instrumentation e.g.: https://github.com/llvm/llvm-project/blob/1784fe0532a69ead17793bced060a9bf9d232027/compiler-rt/test/tsan/java_symbolization.cpp#L5 ThreadSanitizer is now more picky about recursing from runtime callbacks back into runtime. You may either disable these tests, or move callbacks into non-instrumented files (though, will require forking tests), or implement the attribute. Some uses of the disable_sanitizer_instrumentation attribute were also discussed in the Linux kernel context. KMSAN will use it and kernel noinstr functions could use it, though currently noinstr functions are post-processed with kernel's objtool, which nops any sanitizer callbacks. The objtool approach will continue to work, so it's not that the attribute is mandated.
