From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AA0FC3858C2C for ; Fri, 1 Oct 2021 02:56:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA0FC3858C2C Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 1912tsVT031063 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 22:55:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 1912tsVT031063 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B37B41E4A3; Thu, 30 Sep 2021 22:55:53 -0400 (EDT) Message-ID: <62d6eabf-5643-80a5-4d68-1b4728893b5a@polymtl.ca> Date: Thu, 30 Sep 2021 22:55:52 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH v2] gdb: Print debuginfod first-use notification Content-Language: en-US To: Aaron Merey Cc: gdb-patches@sourceware.org, Keith Seitz References: <20210929010906.194578-1-amerey@redhat.com> <51040f26-4ae4-d9e3-a8bd-0b22cd6ee1e3@polymtl.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 1 Oct 2021 02:55:54 +0000 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 02:56:06 -0000 On 2021-09-30 13:03, Aaron Merey wrote: > Hi Simon, > > On Thu, Sep 30, 2021 at 11:41 AM Simon Marchi wrote: >> I don't have a strong opinion on this. If I install GDB from my distro >> and it is pre-configured to fetch files from a remote debuginfo server, >> it would indeed be nice for it to ask for permission first. For >> privacy reasons and those concerned with potential internet >> consumption. >> >> You would have to decide what to do if the first use of GDB is >> non-interactive. Do you default to yes or no? In any case, it would be >> bad because the user might never see the message. So the choices should >> probably be >> >> - yes (and remember) >> - yes (for this session) >> - no (and remember) >> - no (for this session) >> >> And the default in case of non-interactivity would be "no (for this >> session)". >> >> An alternative: I still think it would be nice for the user to be able >> to switch debuginfod usage on and off (and maybe even servers) using a >> GDB setting (rather than changing env vars). So let's say we had a "set >> debuginfod ". The default could be "ask". That would make GDB >> ask "Would you like to use debuginfod for this session?", to which you >> could reply y or n. If the terminal is non-interactive and the state is >> "ask", then we assume "no". >> >> We would also say "To make this setting permanent / avoid this >> question", add "set debuginfod on/off" to your .gdbinit". Then, we >> wouldn't need the debuginfod-used-p file at all I think. If the first >> use of GDB on a system is non-interactive, the user would still see it >> the next time. I would personally put "set debuginfod on" in the >> .gdbinit I carry everywhere, because I am fine with using it. If I >> exceptionally wanted to disable it, I would use `-iex "set debuginfod >> off"`, something like that. > > Personally I'd rather stick to using just the environment variable in > order to control debuginfod. I mentioned in my reply to Keith's original > suggestion that part of debuginfod's appeal is the ability to easily > configure and enable it across a whole system via $DEBUGINFOD_URLS. The "set debuginfod urls" value could be populated at startup with the content of the DEBUGINFOD_URLS env var. That would make it "just work" in GDB by setting DEBUGINFOD_URLS. GDB users are used to configuring GDB using settings. I can't think of anything in GDB that is configurable _only_ using an environment variable. The index-cache default location, for example, is chosen based on the XDG_CACHE_HOME env var, but the user can override it using a setting after that. > If the user has this env var set and they get a (non-interactive) first > use notice in gdb I think it's safe to assume that they are sufficiently > informed and that they had enough opportunity to disable debuginfod if > they preferred. So I don't think that we have much to gain by adding an > extra layer of control via 'set debuginfod on/off/ask'. I don't agree. The user may not see the output of the non-interactive execution. For example, a script/tool that extracts info from a core dump using GDB, a GDB GUI front-end, etc. So they might never see it. Simon