Re: New ThreadSanitizer runtime (v3)

[Marco Elver <elver@google.com>]

On Mon, 22 Nov 2021 at 20:08, Martin Liška <mliska@suse.cz> wrote:
>
> On 11/22/21 20:00, Dmitry Vyukov wrote:
> > 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.
>
> And what about no_sanitize("thread"):
> https://clang.llvm.org/docs/AttributeReference.html#no-sanitize
>
> How is that different from the new attribute?
> Please document how that differs (if you really need the new attribute).

The new attribute is documented here:
https://clang.llvm.org/docs/AttributeReference.html#disable-sanitizer-instrumentation
Specifically "This is not the same as
__attribute__((no_sanitize(...))), which depending on the tool may
still insert instrumentation to prevent false positive reports."
(Some discussion that led to this name is also here:
https://reviews.llvm.org/D108029)

And it seems it's mainly relevant for MSan and TSan, although the
documentation also suggests that it disables all other sanitizers
(which would make it slightly redundant for those other sanitizers vs.
listing all no_sanitize*).

In Clang, for TSan no_sanitize("thread") still inserts
__func_entry/exit and also instrumentation for atomic operations to
avoid false positives; MSan still unpoisons shadow memory in
no_sanitize("memory"), but does not perform checks.

The problem is that certain code just does not want any
instrumentation at all, and we needed an attribute to express that
(e.g. the TSan tests, or some very special Linux-kernel code). We
first discussed having an extension of no_sanitize* attribute, but
some folks didn't like that exactly because it could be confusing and
lead to users using the wrong attribute.

And since this attribute is only supposed to be used very sparingly,
usually in very low level code, to make it clear it's not a substitute
for no_sanitize* it was given this rather distinctive name
"disable_sanitizer_instrumentation".

Now, given you said that GCC also removes __func_entry/exit and atomic
operations from no_sanitize("thread"), this new attribute then seems
redundant for GCC. But then the question is, should GCC's
no_sanitize("thread") be adjusted to avoid false positives?