From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 8FA02385840E for ; Mon, 22 Nov 2021 19:55:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8FA02385840E Received: by mail-ot1-x330.google.com with SMTP id n104-20020a9d2071000000b005799790cf0bso9840696ota.5 for ; Mon, 22 Nov 2021 11:55:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GLrVpV0pX65D/9zKN/tWQLqeC400T3mHG4yyEKIuGqg=; b=33mQaDdC3+Z1Vz4BiSZtdh9n8hGRkUIIgP4LjSkVlAUPX1moP5pmV0cc2mKLHcn2Nc jqm2QtHYqSDfwI5qKI7WmqpR8RfPGvmcV/uVH50Gza2xpm8mIMYUb2wyWBSuVPhKjG/W QX2gYCG36XeH8DuBktQbiVyEr8H1JKm9gynLldmE9Em4q94RvWpBIKOiBMsBh3x2StR8 otDJfxX00JdWdnlsgfjbqtLKEvQ31gOFcBQYAElWONv9BTr4XJihJadWMw4oPKYNfdFA JRaJo+76+Eutv6kF3qgAAmLAmsxN/iQicRr2nQ+ZojGUPRMxGoY7N5EzZyUsN34+eXuS ZzNQ== X-Gm-Message-State: AOAM5307RAzhUeQAncpzZG6NTPiMbwTqdor3B7P1xBpp/65W5Ga0M8nO aHX92tILdGHxc53AWh4k8POSRRWrxGwMZGsRq/JZxw== X-Google-Smtp-Source: ABdhPJzjR8Re/LP87Cm4fX/eo3t5ANkgNxcYTG6kRO81l5ItOvSYUM5ahnHeUrrFtL/3nEjbR/fKfdhE5KGuCA57PH8= X-Received: by 2002:a9d:662:: with SMTP id 89mr26635410otn.157.1637610903698; Mon, 22 Nov 2021 11:55:03 -0800 (PST) MIME-Version: 1.0 References: <1b8fa4e6-7a78-cdbb-c06d-fe7cd58d1e76@suse.cz> In-Reply-To: From: Marco Elver Date: Mon, 22 Nov 2021 20:54:52 +0100 Message-ID: Subject: Re: New ThreadSanitizer runtime (v3) To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Dmitry Vyukov , gcc , ro@gcc.gnu.org, Jakub Jelinek , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-18.2 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 19:55:06 -0000 On Mon, 22 Nov 2021 at 20:08, Martin Li=C5=A1ka 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-instr= umentation 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?