On 11/22/21 16:22, Dmitry Vyukov wrote:
Hi gcc developers,
Hello.
I wanted to give heads up regarding a significant re-design of the
Thanks for it.
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.
That are all good news!
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
Well, apparently the tsan tests (similarly to other Sanitizer) are not
synchronized and we
only have a small subset of test.
Right now I'm working on the libsanitizer's merge from master and tsan.exp
tests work fine.
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.
Right now, we as GCC have no_sanitize ("sanitize_option") that can be used (or
no_sanitize_* attributes).
Can you please explain why did you invent the new flag?
Cheers,
Martin
