From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8893D385840E; Wed, 9 Aug 2023 15:31:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8893D385840E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1691595071; bh=c3dOKbency7swxyj+9kQE+f50+hz/OQpyPwQ7uvibAE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=udttflQKf7fXdW38256SJCnUkAdh5nLjInAn8IP6ySsp8L0tmkRai8uyyndbVcVK4 yitnwITQFVkyFSStDr2EQhbSgAOuAKPdSFgR4hOXVkgiAZqJ0GOo/jKv7E1AoEXIEn dh7/cbUG3EZA7mE23x3M9Qyv5RcP56VZpnr6Z6q0= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/30728] [gdb/symtab, cc-with-dwz] FAIL: gdb.cp/breakpoint-locs.exp: break N1::C1::baz Date: Wed, 09 Aug 2023 15:31:10 +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: 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: 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=3D30728 --- Comment #10 from Tom de Vries --- Reexploring the DW_TAG_inlined_subroutine approach of comment 1 (in combina= tion with the proposed fix for PR30739): ... diff --git a/gdb/dwarf2/cooked-index.h b/gdb/dwarf2/cooked-index.h index 5aacb321c91..d5a2339dd87 100644 --- a/gdb/dwarf2/cooked-index.h +++ b/gdb/dwarf2/cooked-index.h @@ -141,7 +141,7 @@ struct cooked_index_entry : public allocate_on_obstack || tag =3D=3D DW_TAG_constant || tag =3D=3D DW_TAG_enumerator); case FUNCTIONS_DOMAIN: - return tag =3D=3D DW_TAG_subprogram; + return tag =3D=3D DW_TAG_subprogram || tag =3D=3D DW_TAG_inlined_su= broutine; case TYPES_DOMAIN: return tag_is_type (tag); case MODULES_DOMAIN: diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index a64f82bd24a..eef1cffa95d 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -16363,7 +16363,8 @@ cooked_indexer::scan_attributes (dwarf2_per_cu_data *scanning_per_cu, && new_info_ptr > watermark_ptr && *parent_entry =3D=3D nullptr) *maybe_defer =3D form_addr (origin_offset, origin_is_dwz); - else if (*parent_entry =3D=3D nullptr) + else if (*parent_entry =3D=3D nullptr + || abbrev->tag =3D=3D DW_TAG_inlined_subroutine) { CORE_ADDR lookup =3D form_addr (origin_offset, origin_is_dwz); void *obj =3D m_die_range_map.find (lookup); @@ -16616,7 +16617,8 @@ cooked_indexer::index_dies (cutu_reader *reader, case DW_TAG_subprogram: if ((m_language =3D=3D language_fortran - || m_language =3D=3D language_ada) + || m_language =3D=3D language_ada + || m_language =3D=3D language_cplus) && this_entry !=3D nullptr) { info_ptr =3D recurse (reader, info_ptr, this_entry, true); ... What we're trying to achieve here is to add two DW_TAG_inlined_subroutine entries (one for each CU) to the cooked index table, with the parents point= ing to the encapsulating namespace. But, we have: ... [17] ((cooked_index_entry *) 0x4b1f420) name: baz canonical: baz DWARF tag: DW_TAG_inlined_subroutine flags: 0x0 [] DIE offset: 0x148 parent: ((cooked_index_entry *) 0x4b1f240) [C1] ... [19] ((cooked_index_entry *) 0x4b1f570) name: baz canonical: baz DWARF tag: DW_TAG_inlined_subroutine flags: 0x0 [] DIE offset: 0x1cf parent: ((cooked_index_entry *) 0) ... or: ... [5] ((cooked_index_entry *) 0x7fc7b4002f90) name: baz canonical: baz DWARF tag: DW_TAG_inlined_subroutine flags: 0x0 [] DIE offset: 0x148 parent: ((cooked_index_entry *) 0) ... [16] ((cooked_index_entry *) 0x7fc7bc0030b0) name: baz canonical: baz DWARF tag: DW_TAG_inlined_subroutine flags: 0x0 [] DIE offset: 0x1cf parent: ((cooked_index_entry *) 0x7fc7bc002ed0) [C1] ... So, either one or the other has the C1 parent, but we need it for both. The problem is that the m_die_range_map data is limited to the scope of a CU reading session, and we need m_die_range_map data written in one session in another session. Of course that's going to get interesting when the CUs are in different sha= rds. --=20 You are receiving this mail because: You are on the CC list for the bug.=