From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-ss-820.bluehost.com (outbound-ss-820.bluehost.com [69.89.24.241]) by sourceware.org (Postfix) with ESMTPS id BFAC53858C83 for ; Wed, 11 Jan 2023 21:25:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BFAC53858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw12.mail.unifiedlayer.com (unknown [10.0.90.127]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id 20B7910047FA6 for ; Wed, 11 Jan 2023 21:25:36 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id FibIpmfedB18UFibIp6GQk; Wed, 11 Jan 2023 21:25:36 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Ns4Uz+RJ c=1 sm=1 tr=0 ts=63bf2950 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=VJK5EXepP-DpEKxhEz4A:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ppKvSe8aLHBaQThkafcfQE8aHH6eNbn3yIESiJVwEV4=; b=VNzyFfQm4bCp+2WA6oCnEvnPso 2x73EYkBOmApOeOg4HhBCoRqvZhcnmh2iwAMnqHPs9i8CHw06LTgrwocYo4Ypb2WelM8HEHbkPADH BKOCYko5chbUdPuRSsPki4jzS; Received: from 97-122-76-186.hlrn.qwest.net ([97.122.76.186]:51320 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pFibH-003rve-PY; Wed, 11 Jan 2023 14:25:35 -0700 From: Tom Tromey To: Aaron Merey via Gdb-patches Cc: Aaron Merey Subject: Re: [RFC][PATCH] gdb/debuginfod: Support on-demand downloading of debuginfo References: <20221006022424.399932-1-amerey@redhat.com> X-Attribution: Tom Date: Wed, 11 Jan 2023 14:25:32 -0700 In-Reply-To: <20221006022424.399932-1-amerey@redhat.com> (Aaron Merey via Gdb-patches's message of "Wed, 5 Oct 2022 22:24:24 -0400") Message-ID: <87y1q869wz.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.76.186 X-Source-L: No X-Exim-ID: 1pFibH-003rve-PY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-76-186.hlrn.qwest.net (murgatroyd) [97.122.76.186]:51320 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3022.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Aaron" == Aaron Merey via Gdb-patches writes: Aaron> This patch helps address the issue by adding support for on-demand Aaron> downloading and reading of debuginfo. The basic approach it takes is Aaron> to use debuginfod to download just the .gdb_index of a debuginfo file Aaron> as soon as the corresponding library is linked. GDB then relies on the Aaron> information in the index for as long as possible. When the index isn't Aaron> enough then debuginfo is downloaded and read. This helps avoid unnecessary Aaron> downloads. Makes sense to me. Aaron> Although this patch specifically uses .gdb_index, other indexes such Aaron> as .debug_names could be supported in much the same way. I mentioned this in bugzilla, but .debug_names will be worse here because it requires .debug_str and .debug_aranges to be downloaded as well, and the former in particular will contain a lot of data that's not immediately needed. Aaron> This patch adds a command 'set debuginfod enabled lazy' which enables Aaron> on-demand debuginfo downloading/reading. If this 'lazy' mode is enabled Aaron> and a solib's debuginfo cannot be found locally, the new function Aaron> dwarf2_has_separate_index is called in elf_symfile_read. This function Aaron> queries debuginfod servers for the .gdb_index matching the build-id Aaron> of the solib. If it's found, a new objfile is created to hold the .gdb_index Aaron> information. The new objfile flag OBJF_INDEX_READLATER is used to indicate Aaron> that the objfile contains quick_symbols_functions for an index has deferred Aaron> debuginfo reading. It seems to me that OBJF_INDEX_READLATER should not be needed. Instead, what I'd propose is creating the separate debuginfo objfile and providing it with an instance of dwarf2_gdb_index -- but one that arranges to download the remaining data when necessary. It's fine to add new virtual methods to dwarf2_base_index_functions or wherever if this helps. E.g, dw2_instantiate_symtab could be a virtual method in the base class, and then the subclass could override it to first download the remaining sections. You'd have to consider how to handle errors in this situation, but probably just printing a warning (once per file) and carrying on would be good enough. The idea behind warn-and-carry-on is that the user asked for this lazy behavior, if their network goes down then the kind of asked for it; and anyway maybe they can rescue the situation with "noshared" or something. Maybe you tried something like this already and ran into problems? I'm handwaving a lot, maybe there are hidden difficulties. TBH the current gdb design where separate debug files are their own objfile seems like a mistake to me. I haven't ever looked at changing this though. But, maybe it doesn't have to really be changed, dwarf2/read.c could just provide one of these subclasses attached to the parent objfile. Aaron> Also with this patch, GDB will not build with the latest release of Aaron> debuginfod, hence the RFC. The debuginfod ELF/DWARF section query Is it possible to detect the non-existence of debuginfod_find_section at compile time so that we can avoid bumping the minimum requirement? Tom