From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id A10833858C2D; Sun,  1 Jan 2023 22:24:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A10833858C2D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1672611859;
	bh=2FDjw1U8YadDjk+9Uue3ucR6SusAsGrs2ns5dhS/kNg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=DqqzPJ/9eDdp1veqky7iKAmpmK09TjZDFJwtu40MHmHION0j+4pMbxQy0kGlX+vlL
	 3Zv7SXfpi7AX5L6HWNVRw/q1qOqdy7AaQ61eqSetLaTtjgf1sZaXMfrwkiimMCi5/M
	 LbvLmWnoKU+o0bZT6YW2/8uzSVR3IQ3ACEb2T7Sg=
From: "tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/17547] over-eager debuginfo reading
Date: Sun, 01 Jan 2023 22:24:18 +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: <bug-17547-4717-sEBJ4hc7yr@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17547-4717@http.sourceware.org/bugzilla/>
References: <bug-17547-4717@http.sourceware.org/bugzilla/>
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: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D17547

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Frank Ch. Eigler from comment #3)
> (In reply to Christian Biesinger from comment #2)
> > backtrace needs debug data for stack unwinding & showing function names=
 (and
> > arguments)
>=20
> Certainly, but not for ALL solibs, just those implicated in an actual sta=
ck
> frame.

gdb can do some weird stuff for type lookups, so this would need
a bit of careful attention.

Anyway I was wondering recently why gdb isn't using the shared library
memory map to decide which objfiles to search.  That is, surely if
a PC is in some mapped range, then the debuginfo for that function
will come from the corresponding .so.

There's a bunch of loops like:

  for (objfile *objfile : current_program_space->objfiles ())
    {
      struct compunit_symtab *cust
        =3D objfile->find_pc_sect_compunit_symtab (msymbol, pc, section, 0);
      if (cust)
        return;
    }

... that could then be simplified.  On the branch I'm working on
(see bug #29942), this wouldn't improve downloads of debuginfo,
but would improve parsing wait times.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=