From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id AD0773858415 for ; Mon, 22 Nov 2021 15:22:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AD0773858415 Received: by mail-oi1-x229.google.com with SMTP id o4so38412145oia.10 for ; Mon, 22 Nov 2021 07:22:36 -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:from:date:message-id:subject:to:cc; bh=ImCKuOQXhYVvAo06ge8pv/WpafdLvK/hnCQr7LfwDXA=; b=hs/DYhsn9Xj8yyMzSTNaUsxA9YL1TYXqLW/Iw1/InOpO2z3BqIZ5jCRr91dzBS7S6s VSJ4vBoRfMA+k1QIx6HCI51vMwY4EOd0gw3CQXv3lPYxBti12JTqcbybMa2tZ9upHzdh QJMbON606tijtzd8kHpRES9zApwglVzB5GLnmDfsPfgRxvdevtWMnbzfYnI8KJc8kYYr neympTw/Ji/RvZxNRtTES0TYUwGQzZ2yoIpWj10iPvj4p8L+ADoTz8Lm8XyreJh8WX6s Q2yGmWYVZRgE8RbCDhUCwJFahc68DnQ9i6MJurxIMEcyzFGXQl1S40t/58sUfTYRiaT2 0bmg== X-Gm-Message-State: AOAM532r+BhWYoYqtoW9qq6TzBAeIvcMG0jIDt6h1ZOm0OvVOBN66S9b kMMFHNQKsfqv1yfGzYQU2FV2HOZpkwLu+OuaTvzGig9BV2vcXg== X-Google-Smtp-Source: ABdhPJxEnaf/d8sIBuz+U7ObnSIW23nPSBXfm6x9E/hqts9LBG7FYzngkNI8z1iWN6m8GXF/5zqiMd4me+IGF7X/71g= X-Received: by 2002:a05:6808:ec9:: with SMTP id q9mr22066727oiv.160.1637594555627; Mon, 22 Nov 2021 07:22:35 -0800 (PST) MIME-Version: 1.0 From: Dmitry Vyukov Date: Mon, 22 Nov 2021 16:22:24 +0100 Message-ID: Subject: New ThreadSanitizer runtime (v3) To: gcc Cc: ro@gcc.gnu.org, Jakub Jelinek , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Marco Elver , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.0 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 15:22:40 -0000 Hi gcc developers, I wanted to give heads up regarding a significant re-design of the 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. 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 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.