On Mon, 22 Nov 2021 at 20:08, Martin Liška <mli...@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?
