On Mon, 22 Nov 2021 at 19:31, Martin Liška <mli...@suse.cz> wrote:
>
> 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.
Good. But I already reverted the change (some issues on Mac). Plan to
resubmit soon.
> > 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?
Not sure about gcc, but in clang the old no_sanitize_thread attribute
disabled only part of instrumentation (only memory accesses, but not
atomics and function entry/exit). The new attribute disables all
instrumentation.
