From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA1C43858C74; Thu, 5 Jan 2023 01:16:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA1C43858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672881418; bh=46/ZQEG0vA6YKXVh9ygQ0SeLmSPv70270xJIRg6Uc1k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kbvutm7t1s2Sq8tdElyUfQ3sObehnaxUgt4OZNUyiQcvKF2FEfHaGNcxQg9wexdI3 FbadaoHDA95m98V9kNVUE/0Wb/76lFg/sk2abnyxgAdHBug/uNE+WkZ7A1scx5bp5c MVlaHVIFxj5/dD6J2qJIzm9fnsrjNLuoeTlM+wLY= From: "amerey at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/17547] over-eager debuginfo reading Date: Thu, 05 Jan 2023 01:16:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: 7.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amerey at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D17547 --- Comment #11 from Aaron Merey --- (In reply to Tom Tromey from comment #10) > My current work for bug #29942 involves trying to move some gdb work > into the background, so that when many libraries must be read at > once, gdb isn't blocking while processing each one. >=20 > The corresponding idea with debuginfod would be to read the .gdb_index > remotely -- but not even wait for the download to complete before > setting up the "quick_symbol_functions" object. Any code trying to > actually use the index would have to wait for the download to complete, > but this seems fine to me (assuming the user opts in, like in your patch). >=20 > Perhaps another thing that could be done here is to also trigger a > background download of the corresponding full files, so they are > more likely to be available when needed. These are nice enhancements. I'll try prototyping some basic support for background downloading and keep an eye out for your PR29942 patch.=20 > One funny thing here is that while I've been wanting gdb to move > towards the DWARF 5 index (see bug #24820), .gdb_index is > actually more self-contained -- the DWARF 5 index refers to > .debug_str, and gdb also needs .debug_aranges to work. So, .gdb_index > is a little easier for this use. debuginfod supports the downloading of any ELF sections from a given file, so we could implement deferred downloads using=20 .debug_names and related sections in addition to .gdb_index or instead of it. Even if we keep using .gdb_index for this we still may end up downloading other sections. One issue with deferred downloads that I'd like to address: commands that require searching debuginfos for a source file name trigger a mass download of all deferred debuginfo, since .gdb_index doesn't contain file name information. Maybe gdb could get this information from downloading .debug_line/.debug_line_str in addition to .gdb_index. --=20 You are receiving this mail because: You are on the CC list for the bug.=