From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E197F3858D39; Tue, 8 Aug 2023 12:01:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E197F3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1691496066; bh=GI3Q8cWc/B+lKnuEmfsgI+pHtMioGNl4pZqFfq+XpF0=; h=From:To:Subject:Date:From; b=ma66zdKAr2FmzcU6GBHppp3BKhyXB1KtcbPhR8t9JljBpkyJPtEEkvph66Q7IMkti FyPKXKWBBOcdzJ+UVvy+2GMeYJ43QKAisISErGBL5cWGe5nVVz0uYWV3bHiEy9tFE3 evYB7qD7pdUiETVNv6pfzK5HkfLhd5FceR6BjQtw= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/30736] New: [gdb/symtab] Result of cooked_index_functions::expand_symtabs_matching depends on expansion state Date: Tue, 08 Aug 2023 12:01:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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=3D30736 Bug ID: 30736 Summary: [gdb/symtab] Result of cooked_index_functions::expand_symtabs_matching depends on expansion state Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- I was looking at cooked_index_functions::expand_symtabs_matching and came across: ... /* No need to consider symbols from expanded CUs. */ if (per_objfile->symtab_set_p (entry->per_cu)) continue; ... and had trouble understanding this. My understanding of how a lookup should work is: - find the set of relevant symtabs - make sure they're expanded - do the lookup in the set of relevant expanded symtabs Then, there are roughly two modes of lookup: - find the first match, and - find all matches The code snippet above fits well with the "find all matches" approach. If we're iterating to ensure all relevant symtabs are expanded, and a symta= b is already expanded, no need to consider it further, regardless of whether it's relevant or not. But if we're iterating to find the first relevant symtab and make sure it's expanded, the code snippet make sure that subsequent lookups will find a different first match. This is similar to PR25857. If we apply the tentative fix for PR25857 (reverse order in lookup_symbol_in_objfile), we can demonstrate this PR using a similar test-case: ... $ cat test.c static int aaa =3D 2; int main (void) { return 0; } $ cat test-2.c static int aaa =3D 1; $ gcc -g test.c test-2.c $ gdb -q -batch -iex "set trace-commands on" a.out \ -ex "print aaa" \ -ex "maint info symtabs" \ -ex "maint flush symbol-cache" \ -ex "print aaa" \ -ex "maint info symtabs" +print aaa $1 =3D 2 +maint info symtabs { objfile /data/vries/gdb/a.out ((struct objfile *) 0x4b451f0) { ((struct compunit_symtab *) 0x4b3d280) debugformat DWARF 4 producer GNU C11 7.5.0 -mtune=3Dgeneric -march=3Dx86-64 -g name test.c dirname /home/vries/gdb blockvector ((struct blockvector *) 0x4b3d760) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x4b3d300) fullname (null) linetable ((struct linetable *) 0x4b3d790) } } } +maint flush symbol-cache +print aaa $2 =3D 1 +maint info symtabs { objfile /data/vries/gdb/a.out ((struct objfile *) 0x4b451f0) { ((struct compunit_symtab *) 0x4b3d800) debugformat DWARF 4 producer GNU C11 7.5.0 -mtune=3Dgeneric -march=3Dx86-64 -g name test-2.c dirname /home/vries/gdb blockvector ((struct blockvector *) 0x4b3db00) user ((struct compunit_symtab *) (null)) { symtab test-2.c ((struct symtab *) 0x4b3d880) fullname (null) linetable ((struct linetable *) 0x0) } } { ((struct compunit_symtab *) 0x4b3d280) debugformat DWARF 4 producer GNU C11 7.5.0 -mtune=3Dgeneric -march=3Dx86-64 -g name test.c dirname /home/vries/gdb blockvector ((struct blockvector *) 0x4b3d760) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x4b3d300) fullname (null) linetable ((struct linetable *) 0x4b3d790) } } } ... In other words: - lookup aaa is done, symtab test.c matches and is expanded - value of aaa in test.c is printed - symbol-cache is flushed (otherwise we're guaranteed to have the same value, and no actual lookup is done) - another lookup of aaa is done, symtab test.c is skipped because it's alre= ady expanded, symtab test-2.c matches and is expanded - value of aaa in test-2.c is printed --=20 You are receiving this mail because: You are on the CC list for the bug.=