From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HdTABLwnFmhA9xIAWB0awg (envelope-from ) for ; Sat, 03 May 2025 10:27:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1746282427; bh=7Lz4AxIZclolc8D+o798WlJxXF9fYjfvRGU3uuguQFg=; h=Date:Subject:From:To:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=NPskXMmF+qIs9eGkHwE08oR6qSnDzbhqe1WSuDDwJIsjh7noEN3NDl8wERnUSYKmS EsecAhX7t+PaoOzyceI9SsHmZ6i5uAiGTuvGOgGQ2Xwcr8cFDvwqBVxggZqDoiP+iR fK8vnibVyhgwNinC3Kh5DtMkANAML4X/cmUd2mO8= Received: by simark.ca (Postfix, from userid 112) id EF6761E10E; Sat, 3 May 2025 10:27:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=w1Q1CfS+; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=RYqfSoKc; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4CE761E089 for ; Sat, 3 May 2025 10:27:05 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E2EA8385841D for ; Sat, 3 May 2025 14:27:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2EA8385841D Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=w1Q1CfS+; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=RYqfSoKc Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 8A3003858D21 for ; Sat, 3 May 2025 14:26:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A3003858D21 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8A3003858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1746282391; cv=none; b=GQqMUfADzDum/08PN22L2p+esN3gXQ4PwBguF8GOg3Pix/ghokIAhqNlsJqnHVJk9NCc1JyiaAF+NTqumGXftl+wjAESbL9PqRZ5Ee8z0Yf8Nu4eBT5EZhA8dr6mvNOJQhSTe95V8cZrGJvI9qd0NZbx5EKD9eMEomrcSPQ3G1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1746282391; c=relaxed/simple; bh=7Lz4AxIZclolc8D+o798WlJxXF9fYjfvRGU3uuguQFg=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:From:To; b=MXiDqe+J5MVNjM0wdMlyjPDaZGurwOY1OEwgvIBwhMhdy8/yKIyeRgn+6OA3vzkmKA0i+6dWJIdL20DzN28ltD0f5DTjGMBmJR6HXCeqKrbsHNca7IL4FCjwsfJbUGfnFihyi7kayauyykhIQnOhIqQbAlIIQraRZjNjh9wXlEE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A3003858D21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1746282391; bh=7Lz4AxIZclolc8D+o798WlJxXF9fYjfvRGU3uuguQFg=; h=Date:Subject:From:To:References:In-Reply-To:From; b=w1Q1CfS+UurpcXg0vEfmqKZuweEEeXcR1M1DzKToq5Jln6LKW7Ua6aaMvqkI7rL3X 94NOOYNVgQvkV4DdYi9BvCgTvu9yXFA20oNpnxjdyUePR2sx78/5rwjJlKx9PMM/VL QnYXZIHDEa3ZKr2Ah9JE1v+109V3vPXjEaSBo9pw= Received: by simark.ca (Postfix, from userid 112) id 45FAB1E114; Sat, 3 May 2025 10:26:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1746282389; bh=7Lz4AxIZclolc8D+o798WlJxXF9fYjfvRGU3uuguQFg=; h=Date:Subject:From:To:References:In-Reply-To:From; b=RYqfSoKclV594wW9w1lVgMf3jSLWZGVWy2pm91kexsWLoEtYjssMQAOtpB1cpinqO 0ramTe1EezMwADt9ISKM+Zob0Ei3rB3/bMCqV//TseLgjrz6BhlCmA3Aqhx0cPp2D7 PeF1lp2SnjwEJ3AipgodwxqcRJSVsbnz5HBHdYGQ= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 98DC81E089; Sat, 3 May 2025 10:26:29 -0400 (EDT) Message-ID: Date: Sat, 3 May 2025 10:26:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fix "set debug parser" From: Simon Marchi To: Tom Tromey , gdb-patches@sourceware.org References: <20250426231242.926679-1-tom@tromey.com> <0dfbab20-4262-4dca-b2dd-fece5f93df08@simark.ca> Content-Language: en-US In-Reply-To: <0dfbab20-4262-4dca-b2dd-fece5f93df08@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2025-05-02 16:30, Simon Marchi wrote: > > > On 2025-04-26 19:12, Tom Tromey wrote: >> While debugging my longer series, I discovered that I broken "set >> debug parser" a couple years ago. This patch fixes it and adds a >> minimal test case so that it, hopefully, will not break again. >> >> This patch also adds parser debugging to the C++ name canonicalizer. > > I think this introduced some tsan failures, since multiple threads write > yydebug without synchronization: > > WARNING: ThreadSanitizer: data race (pid=1311054) > Read of size 4 at 0x58c55ad4a1f0 by thread T5: > #0 scoped_restore_tmpl::scoped_restore_tmpl(int*, bool) /home/simark/src/binutils-gdb/gdb/../gdbsupport/scoped_restore.h:71 (gdb+0xb7a0fe) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > #1 scoped_restore_tmpl make_scoped_restore(int*, bool) /home/simark/src/binutils-gdb/gdb/../gdbsupport/scoped_restore.h:115 (gdb+0xb6bdbd) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > #2 cp_demangled_name_to_comp(char const*, std::__cxx11::basic_string, std::allocator >*) /home/simark/src/binutils-gdb/gdb/cp-name-parser.y:2051 (gdb+0xfaec69) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > #3 cp_canonicalize_string(char const*) /home/simark/src/binutils-gdb/gdb/cp-support.c:635 (gdb+0xfbf01d) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > #4 c_canonicalize_name(char const*) /home/simark/src/binutils-gdb/gdb/c-lang.c:732 (gdb+0xe70f6f) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > #5 cooked_index_shard::finalize(parent_map_map const*) /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index-shard.c:273 (gdb+0x104cbcf) (BuildId: 8f118bec5111347e0f2a78a7dc2fed594eb4ef55) > > Changing yydebug to be an std::atomic would probably fix it, but it's > generated by bison, not sure this is an option. We'll probably need to > do a custom scoped restore type for this. > > Simon I gave this a try, and it's actually not as easy as that. While we can lock where we write to yydebug, we can't easily lock where we read yydebug, because it is in bison-generated code. So it still triggers TSan. Also, I'm not sure that it's a good idea to restore yydebug (i.e. to use scoped_restore). Imaging that parser_debug is 1, meaning that the intention is to print debug output. - Thread 1 saves yydebug's old val (0) and sets yydebug to 1 - Thread 2 saves yydebug's old val (1) and sets yydebug to 1 - Thread 1 executes the rest of the function, printing debug output, restores yydebug to 0 when exiting - Thread 2 executes the rest of the function, but does not print debug output, since yydebug was reset by thread 1 (that's bad) - Thread 2 restores yydebug to 1 when exiting It doesn't really matter we leave yydebug set at when exiting, it only matters that on entry, we set it to the value we want (parser_debug). So we should just do this on entry: yydebug = parser_debug; It should work well even with multiple threads, but TSan will still warn. I am not sure if it's a race condition we really care about, but it would still be nice to make TSan happy to make debugging important races easier. The only idea I have right now is to run a "sed" after generating cp-name-parser.c, to change the type of "int yydebug" to either an atomic or a thread_local variable, whichever incurs the lowest read-side cost. Simon