From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by sourceware.org (Postfix) with ESMTPS id 737A6385828E for ; Tue, 5 Jul 2022 04:22:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 737A6385828E Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-31c8340a6f7so56185477b3.4 for ; Mon, 04 Jul 2022 21:22:02 -0700 (PDT) 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; bh=g8O/OEN++WtQqDb2rKtV3ev0vFzSP6bqKyewuDLNjKs=; b=TB03/2g3S4y4LmHJgyzJSQTwbT2jYh+3RH6vCv5xO4jnVb37vgrNqX4R+7i8AzvJvK peZ+s7ZFcFIDxdkX9S4Lf8axDZBrGNzs9w5P892x85BbGrmBLBM5puiuM16oSKgc0UwQ jShU/62nX96HXSDaRLhHf97VyzxpAZlTUI1vuAu69R1OWFpt1+gyR9L7biVF6rUxzM2c Tr92OnjFBl90Raitu1foMXoo9hIEObBtkTzt7dAhTzeeSZZ3XNA1H6YcqxeH4R63efPM R1gFpOS6oaGRiWFkftkoEVqMgMJzwFvqfOuAwgpJskU5tC4zRW/YjmaJy0ezxTjsLABG WPiw== X-Gm-Message-State: AJIora8AhTH7rB74m0lmyw0EKSxLQgghYjOZKTihXXrjSDFqjMqORn0B S7/sd9qTQt3GnhQbLs8scUYUDeAq3WzYoVKrKvYynw== X-Google-Smtp-Source: AGRyM1s1+yhmkq3mwuPJ1tCZGJl1JbvAr3+AwLZczgFedtwjQ4gAw/dDq0lZB+ajg7hBqTVUmRYsqYk8qk77NrWZBH4= X-Received: by 2002:a0d:d8c8:0:b0:31c:92b1:5dec with SMTP id a191-20020a0dd8c8000000b0031c92b15decmr11018973ywe.19.1656994921663; Mon, 04 Jul 2022 21:22:01 -0700 (PDT) MIME-Version: 1.0 References: <7e4db89fea59f636afd7abce981cc625d940b5cd.camel@xry111.site> In-Reply-To: <7e4db89fea59f636afd7abce981cc625d940b5cd.camel@xry111.site> From: Fangrui Song Date: Mon, 4 Jul 2022 21:21:50 -0700 Message-ID: Subject: Re: [PATCH] Mips: Enable asynchronous unwind tables with both ASAN and TSAN To: Xi Ruoyao Cc: Dimitrije Milosevic , "gcc-patches@gcc.gnu.org" , Djordje Todorovic Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-24.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 04:22:07 -0000 On Mon, Jul 4, 2022 at 6:54 PM Xi Ruoyao via Gcc-patches wrote: > > On Mon, 2022-07-04 at 14:28 +0000, Dimitrije Milosevic wrote: > > On Saturday, June 11, 2022 2:03 PM, Xi wrote: > > > Just tried TSAN_SUPPORTED=yes with asynchronous unwind tables > > > enabled, > > > but I got some strange test failures for tls_race.c: > > > > > > FAIL: c-c++-common/tsan/tls_race.c -O0 output pattern test > > > Output was: > > > ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:452 > > > "((thr_end)) <= ((tls_addr + tls_size))" (0xffec35f8c0, > > > 0xffec35f784) (tid=748216) > > > #0 __tsan::CheckUnwind() > > > ../../../../gcc/libsanitizer/tsan/tsan_rtl.cpp:627 > > > (libtsan.so.2+0xa30ec) > > > #1 __sanitizer::CheckFailed(char const*, int, char const*, > > > unsigned long long, unsigned long long) > > > ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_termination. > > > cpp:86 (libtsan.so.2+0xeb8cc) > > > #2 __tsan::ImitateTlsWrite(__tsan::ThreadState*, unsigned long, > > > unsigned long) > > > ../../../../gcc/libsanitizer/tsan/tsan_platform_linux.cpp:452 > > > (libtsan.so.2+0xa0cac) > > > #3 __tsan::ThreadStart(__tsan::ThreadState*, unsigned int, > > > unsigned long long, __sanitizer::ThreadType) > > > ../../../../gcc/libsanitizer/tsan/tsan_rtl_thread.cpp:197 > > > (libtsan.so.2+0xc0e88) > > > #4 __tsan_thread_start_func > > > ../../../../gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1009 > > > (libtsan.so.2+0x3e5dc) > > > #5 start_thread /sources/glibc-2.35/nptl/pthread_create.c:442 > > > (libc.so.6+0xc75f4) > > > > > > I've tried to diagnose the root cause but failed. > > > > Hi Xi, thanks for looking into this. I've tried running the testsuite > > on a cross-toolchain (as I do not currently have access to a physical > > machine) > > for a MIPS64R6 and the test passes successfully. Could you please > > verify that the test fails solely based on this change? > > I guess you mean you are running MIPS64R6 target code with qemu? I'm > not 100% sure because maybe something is wrong in my system. I'm now > retrying on gcc230.fsffrance.org (an EdgeRouter 4 in Cfarm) but building > GCC on it is really slow. > > The changes I've tested: > > diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc > index 5eb845960e1..a7f0580e9ba 100644 > --- a/gcc/config/mips/mips.cc > +++ b/gcc/config/mips/mips.cc > @@ -20115,10 +20115,11 @@ mips_option_override (void) > target_flags |= MASK_64BIT; > } > > - /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables in > - order for tracebacks to be complete but not if any > - -fasynchronous-unwind-table were already specified. */ > - if (flag_sanitize & SANITIZE_USER_ADDRESS > + /* For -fsanitize=address or -fsanitize=thread, it's needed to turn > + on -fasynchronous-unwind-tables in order for tracebacks > + to be complete but not if any -fasynchronous-unwind-table > + were already specified. */ > + if (flag_sanitize & (SANITIZE_USER_ADDRESS | SANITIZE_THREAD) > && !global_options_set.x_flag_asynchronous_unwind_tables) > flag_asynchronous_unwind_tables = 1; > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt > index fb89df4935c..52546bbe4e3 100644 > --- a/libsanitizer/configure.tgt > +++ b/libsanitizer/configure.tgt > @@ -55,6 +55,9 @@ case "${target}" in > arm*-*-linux*) > ;; > mips*-*-linux*) > + if test x$ac_cv_sizeof_void_p = x8; then > + TSAN_SUPPORTED=yes > + fi > ;; > aarch64*-*-linux*) > if test x$ac_cv_sizeof_void_p = x8; then > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University Drive-by comment. Clang considers that asan/msan/tsan/dataflow/etc enables -fasynchronous-unwind-tables by default so I assume this GCC change is fine. With https://reviews.llvm.org/D102046 ("[sanitizer] Fall back to fast unwinder"), compiler-rt may fall back to the frame pointer based unwinder. There is not strong need to have the default -fasynchronous-unwind-tables or -funwind-tables behavior. However, most targets still default to omit frame pointer, so it's a bit unfortunately that we need to enable unwind tables to get good diagnostics.