From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13124 invoked by alias); 20 Feb 2020 18:50:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13041 invoked by uid 89); 20 Feb 2020 18:50:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=surprised X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Feb 2020 18:50:13 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (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 6E1591E5FA; Thu, 20 Feb 2020 13:50:11 -0500 (EST) Subject: Re: [PATCH v3] Add debuginfod support to GDB From: Simon Marchi To: Aaron Merey , gdb-patches@sourceware.org Cc: Tom Tromey , Christian Biesinger References: Message-ID: <4d971725-4f83-a1d3-80a2-9e54a78c6e56@simark.ca> Date: Thu, 20 Feb 2020 18:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00835.txt.bz2 On 2020-02-20 1:02 p.m., Simon Marchi wrote: > I think we still need something just after the debuginfod_find_debuginfo > and debuginfod_find_source calls to throw the "quit" exception, if the quit > flag is set at this point. Without that, the debuginfod_source_query and > debuginfod_debuginfo_query will return a failure. The calling code could > therefore conclude that debug info is not available (and cache that value > somehwere), for a file for which debug info is actually available. When > the execution reaches the event loop and we process the quit flag, it > would be too late, the damage will have been done. Following a discussion on IRC, I changed my mind, the simplest solution for now would be: when the user cancels a download, GDB will continue as if debug info was not available for that objfile. However, I would suggest printing a message saying that the download of debug info for XYZ was cancelled, so the user is not surprised to not have its debug info. Simon