From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6D1323857404; Tue, 25 May 2021 21:24:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6D1323857404 From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug symtab/17547] over-eager debuginfo reading Date: Tue, 25 May 2021 21:24:05 +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: tromey at sourceware dot org 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 21:24:06 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17547 --- Comment #7 from Tom Tromey --- Once upon a time, I added lazy reading to gdb. The vestiges are still in the tree, search for OBJF_PSYMTABS_READ and SYMFILE_NO_READ. The use case was precisely what Frank is talking about - "attach" was very slow and read a bunch of irrelevant stuff. However, this was mostly disabled. While it works great for some scenarios, it also causes long pauses at "unexpected" times in other scenarios. For example, it makes "backtrace" randomly slow, depending on whether the debuginfo for a frame has been read. (The "backtrace" problem can be solved as well, by lazier reading of the DWARF. This is a reasonably-sized project though.) Another problem is that setting a breakpoint becomes very expensive, because most breakpoints require a full DWARF scan. This too is avoidable, at least partly, if there were a way to isolate breakpoints to a given .so or whatever; or by the use of an index. When disabling this feature, I think our rationale was that it's better for users to get the delays up front, when they expect them, rather than randomly in response to some command. What would be truly great for something like debuginfod is to have it index all the libraries, and then provide a fine-grained API to gdb. Then with some work, gdb could avoid ever downloading all the DWARF or doing a massive scan. --=20 You are receiving this mail because: You are on the CC list for the bug.=