From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UMXyIlHaxWds5wMAWB0awg (envelope-from ) for ; Mon, 03 Mar 2025 11:35:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741019729; bh=XmtQsZbp4FKbri1IytvDcPudDVk/knGWrHetCzXPWns=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kHQREMG0cHKHqJUCaah00N8K0y9NQ8C3u00Q00cYko/mEre6fbIYtyD0UQHQp1glD 6yNchp0xdZ/dW82pjLaOn9f9Sv6ZdsDd0UFwi7MXWQO5TMFAILlwlV7wh5djTLk+nS UKNIoVq9JqR4BKYvBVGulFRq9QvNWhVrT60WBYhE= Received: by simark.ca (Postfix, from userid 112) id 810A31E105; Mon, 3 Mar 2025 11:35:29 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 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=CuXxpQcy; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=bi5KJp7c; 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 192181E05C for ; Mon, 3 Mar 2025 11:35:29 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 91CE73858D3C for ; Mon, 3 Mar 2025 16:35:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91CE73858D3C 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=CuXxpQcy; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=bi5KJp7c Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DFE6C3858CD1 for ; Mon, 3 Mar 2025 16:31:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFE6C3858CD1 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 DFE6C3858CD1 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=1741019509; cv=none; b=TecDIAIgt0V9rBY757cELsus90VHKqSls61f9eMgD3XM+yiWLU/VlSIEFEZM9QvzcutqjLSYXWIBaaawmZu6419ep5G0CpqanFMqoVBu9r8A2pnIyGtjuXDGXiWwywLgDd1lS4AlGK2IvL16tHVuKIxNz1Db5AW7l0byH5EZ6XU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741019509; c=relaxed/simple; bh=XmtQsZbp4FKbri1IytvDcPudDVk/knGWrHetCzXPWns=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=xoqk08VB+DQDnjcQmRUE4dz9fnBfhcTzDBU68MPq/p0gdHAvAylySS/G9esWxrlUD/jTDQxIrWSqvOBcMcc7qA9jznoms65UPbmKP1uGYPjAk5IJmNwbnaKsAFZgpYmrJ3VZf+KKgBf/YMARgQgCmhVRztmuZzV9ydw1x3mCNdU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFE6C3858CD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741019508; bh=XmtQsZbp4FKbri1IytvDcPudDVk/knGWrHetCzXPWns=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CuXxpQcyLerTfEaQHYtBnj299JXReVog/CD0DMI+ZfTNf2Df9W/8KcuKBOisIC0u/ vwdL250yX5tXKulvdq6FHmVxw/TTpjI8IJO2Tmnz+7+xUzK//+diLQYE7ByjNOlZrx YZNwhBFpIRPHlkLwd2JmGQhUyqMliyUOQj7R2KnA= Received: by simark.ca (Postfix, from userid 112) id 985B11E10A; Mon, 3 Mar 2025 11:31:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741019507; bh=XmtQsZbp4FKbri1IytvDcPudDVk/knGWrHetCzXPWns=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bi5KJp7c32T5SPF93iDbXQyKKttpI3BvTB38eAA1utD8N2Q5Cmj8u3fUG02runyql uEc52sHXlVg0oMKVha4tSYqjdeW2xWG/E9vf50S+pVIQ4McA+7VfxPwVupOR33yBjR oXqpb36q7j1lNMH42rnw1Vq/VgHvTLuhOFBYg2lY= Received: from [172.16.0.192] (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) (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 908351E05C; Mon, 3 Mar 2025 11:31:47 -0500 (EST) Message-ID: <117200f3-59f6-41d1-91ba-abc9089a1734@simark.ca> Date: Mon, 3 Mar 2025 11:31:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: add load-libthread-db-quietly option To: Eli Zaretskii Cc: gregory@heytings.org, gdb-patches@sourceware.org References: <865xktq8gw.fsf@gnu.org> <8634fwq1sr.fsf@gnu.org> <9ab7816e-716b-432d-ac69-8c311ce2f38c@simark.ca> <86bjuiktq9.fsf@gnu.org> Content-Language: fr From: Simon Marchi In-Reply-To: <86bjuiktq9.fsf@gnu.org> 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 3/3/25 10:40 AM, Eli Zaretskii wrote: >> Date: Mon, 3 Mar 2025 09:59:25 -0500 >> Cc: gdb-patches@sourceware.org >> From: Simon Marchi >> >> People ask us to make it possible to turn this or that message on and >> off all the time. The proposed command, "set >> load-libthread-db-quietly", is very specific to that use case. Could we >> add perhaps a prefix command (or find an existing appropriate one) that >> would allow us to easily add more such knobs? I'm thinking of something >> like (maybe not a good name, but just for the example): >> >> (gdb) set message load-libthread-db on/off > > Sure, why not. But we'd need some infrastructure for each command to > be able to determine whether it was asked to be quiet, won't we? I'm not saying we need special infrastructure in the code to handle this, but just to regroup similar settings under the same prefix, to keep them together and consistent. Simon