From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 822B53858C20; Fri, 26 Jan 2024 15:43:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 822B53858C20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1706283805; bh=AAgiH0rY8DZRJoK9DPIyq9pG0GQ1Znw1pyFHld4IR38=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nPfPkV2jTTn4EtQ8nat73DuDC/6e2VsknEmIAnALkercmGiAaIhAdlxe830MX1Zh2 BrCiWkzpWASV+ZQEwDW+HqOr7rPQLnon2bkOETqCVdR2pVGFCtkRUFMyr5w66sQy79 02uEtSrD0AzPTcwPW02ec9+/FJB+rm3fW/XKRAw4= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/31295] Slow symbol lookup due to missing DW_AT_const_value attribute Date: Fri, 26 Jan 2024 15:43:25 +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: 14.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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=3D31295 --- Comment #6 from Tom de Vries --- (In reply to Dmitry Neverov from comment #5) > Created attachment 15335 [details] > repro without grepping symtabs >=20 > Maybe I'm misinterpreting results, but I think I can reproduce it if I dr= op > grep in your script: util.cpp appears after 'print str'. Thanks for posting your logs, that helped me figure it out. FWIW, AFAIU the grep was not the problem (but dropping the grep gave me the info I needed). Your three logs all use gcc 12, as far as I can tell from the producer stri= ngs. Since gcc-11, dwarf-5 is the default. But the gcc-12 package I'm using defaults to dwarf-4. So, after hardcoding -gdwarf-5, I was able to reproduce it (with trunk btw). I've looked at the difference, and with dwarf4 for main we have: ... <1><2445>: Abbrev Number: 10 (DW_TAG_class_type) <2446> DW_AT_name : wxString <244a> DW_AT_byte_size : 16 <2><2452>: Abbrev Number: 80 (DW_TAG_member) <2453> DW_AT_name : npos <245a> DW_AT_type : <0xd2d> <245e> DW_AT_external : 1 <245e> DW_AT_accessibility: 1 (public) <245f> DW_AT_declaration : 1 ... and with dwarf5: ... <1><2a96>: Abbrev Number: 27 (DW_TAG_class_type) <2a97> DW_AT_name : wxString <2a9b> DW_AT_byte_size : 16 <2><2aa3>: Abbrev Number: 28 (DW_TAG_variable) <2aa4> DW_AT_name : npos <2aab> DW_AT_linkage_name: _ZN8wxString4nposE <2aaf> DW_AT_type : <0x2510> <2ab3> DW_AT_external : 1 <2ab3> DW_AT_accessibility: 1 (public) <2ab4> DW_AT_declaration : 1 ... There are two difference: DW_TAG_member vs DW_TAG_variable, and the presence/absence of DW_AT_linkage_name. So, with dwarf4, we have no npos entries in the cooked index: ... $ gdb -q -batch main -ex "maint print objfiles" | grep npos $ ... and with dwarf5, we do: ... $ gdb -q -batch main -ex "maint print objfiles" | grep npos name: _ZN8wxString4nposE canonical: _ZN8wxString4nposE qualified: _ZN8wxString4nposE name: npos canonical: npos qualified: wxString::npos name: _ZN8wxString4nposE canonical: _ZN8wxString4nposE qualified: _ZN8wxString4nposE name: npos canonical: npos qualified: wxString::npos $ ... FWIW, in both cases we have the linkage symbol in main, dwarf4: ... $ nm main | grep npos 0000000000401da0 D _ZN8wxString4nposE ... and dwarf5: ... $ nm main | grep npos 0000000000401da0 D _ZN8wxString4nposE ... though it's a dynamic one. --=20 You are receiving this mail because: You are on the CC list for the bug.=