From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id E2EAF385801B for ; Mon, 22 Nov 2021 19:00:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2EAF385801B Received: by mail-ot1-x332.google.com with SMTP id n104-20020a9d2071000000b005799790cf0bso9638259ota.5 for ; Mon, 22 Nov 2021 11:00:50 -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=OSB8/1ya21JDHVQNyH8OLGWiOOwJxS7mo520sjDC4Q4=; b=OHvZqu9Rp84iEAdAUJ6Jo/slvi502SVHMMdn++3mnA3NHC3Crdn1i/wwRfy7Ot9qft mzVDBr2gTXwkDwhIGsg9Y9HFu5yhPtjw+7nF9Dm20UU+eJBCixMIsGTUxtqIoMarYiq1 vlo/2d90N9Hr6wF3mhysFdHTDbAVIISVn6gy4b6jAEuhi7H1DttbhIx6OlbdjaZLscqP pFAmbhYx4+h5WfNXb8l4WGefuC4AfZ+4eIaC7b3e3zf6Qhqvd39ubJPgEGCWo2Dxu0y6 DaxHN2JuXEUFm8zvPAr+ieCBA7ifrqpu9Q+cakRR/YA2FZds8/B+z3AK6654jU1oLK6c aJIw== X-Gm-Message-State: AOAM532qK6l8b7dAMwcmFnomKX6IEJTBMQC4CZL2NGR4GkH2mdfMNYEx qMy8Lty3cC4/TamhYoO8Hec2pYJQxYmvejpsvP7S3A== X-Google-Smtp-Source: ABdhPJxHauogorW6XK1Pv8qQxZeV0Gd3Ok5dMET85m1YCzEU6WBfvaLKFRewJ7FCivKP7rd8MJ5vrAfKKe/nD0Vd9BY= X-Received: by 2002:a05:6830:1356:: with SMTP id r22mr26029464otq.196.1637607649998; Mon, 22 Nov 2021 11:00:49 -0800 (PST) MIME-Version: 1.0 References: <1b8fa4e6-7a78-cdbb-c06d-fe7cd58d1e76@suse.cz> In-Reply-To: <1b8fa4e6-7a78-cdbb-c06d-fe7cd58d1e76@suse.cz> From: Dmitry Vyukov Date: Mon, 22 Nov 2021 20:00:38 +0100 Message-ID: Subject: Re: New ThreadSanitizer runtime (v3) To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: gcc , ro@gcc.gnu.org, Jakub Jelinek , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Marco Elver , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-18.6 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=ham 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:00:52 -0000 On Mon, 22 Nov 2021 at 19:31, Martin Li=C5=A1ka 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/1784fe0532a69ead17793bced06= 0a9bf9d232027 > > 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-i= nstrumentation > > e.g.: > > https://github.com/llvm/llvm-project/blob/1784fe0532a69ead17793bced060a= 9bf9d232027/compiler-rt/test/tsan/java_symbolization.cpp#L5 > > Well, apparently the tsan tests (similarly to other Sanitizer) are not sy= nchronized and we > only have a small subset of test. > > Right now I'm working on the libsanitizer's merge from master and tsan.ex= p 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 use= d (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.