From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120005 invoked by alias); 5 Nov 2019 05:27:27 -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 119955 invoked by uid 89); 5 Nov 2019 05:27:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:server-, H*r:10.0.0, offer, day 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; Tue, 05 Nov 2019 05:27:25 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 546161E4C2; Tue, 5 Nov 2019 00:27:23 -0500 (EST) Subject: Re: [RFC PATCH] Support debuginfo and source file fetching via debuginfo server To: Aaron Merey , "Frank Ch. Eigler" Cc: Tom Tromey , Christian Biesinger via gdb-patches , Christian Biesinger References: <20190820202809.25367-1-amerey@redhat.com> <87pnj6dl3k.fsf@tromey.com> <87sgn71ji6.fsf@tromey.com> <87lfsye5l5.fsf@redhat.com> <87bltrelab.fsf@redhat.com> <20191104162616.GA13319@redhat.com> From: Simon Marchi Message-ID: <6f3fb81a-09ef-ab07-eef4-0460181bcaa0@simark.ca> Date: Tue, 05 Nov 2019 05:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-11/txt/msg00113.txt.bz2 On 2019-11-04 8:59 p.m., Aaron Merey wrote: > On Mon, Nov 4, 2019 at 11:26 AM Frank Ch. Eigler wrote: >> >> Hi - >> >>> I haven't followed this thread closely, so it might be an obvious "no", but >>> I was wondering if the library could offer to install a callback that is call >>> relatively often, allowing GDB to interrupt the operation [...] >> >> That could also work, at the cost of extending the API. Will play with it. >> >> - FChE > > Attached is the updated debuginfo and source lookup code, using the > callback idea that Simon suggested. Downloads are now cancelled upon > SIGINT and the callback can be modified with code that prints progress > messages (the a and b parameters in the callback represent the > numerator and denominator of the download's completion fraction). Cool, thanks! Maybe a user_data void pointer would be useful, to be able to get some context in the callback? I am noticing that debuginfod calls don't have any "context" or "handle" parameters, which could suggest that the state of the library (if there is any) is kept as global variables. Is it safe to use the library to do lookups in parallel, from different threads? It is possible that GDB or another program will want to do that some day. Simon