From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 68A953861831; Thu, 5 Oct 2023 13:09:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68A953861831 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1696511364; bh=vWdgChKtsWsBEKPwJw8a3EMpBuR3ZhWq1NO6GRQAxjs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aLixBWv8f0NGFTzcwbvcCBj0X73VSsagJTGlm8pZ3fpMG2BXwMNolmzcym7U4M/kH ShlotYGNkrocf2sd5QOPoWnYNPq18KI+i9h8ba18nI4iJtd0MNEsLwbir10mCst1jR qU47r+aUrCgPMQKMdOOOIsr48p3iu/pq0eAvy13w= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug go/30941] [gdb/go] cannot find package2.Foo in expanded symtab containing go.package2.Foo Date: Thu, 05 Oct 2023 13:09:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: go 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=3D30941 --- Comment #1 from Tom de Vries --- The dwarf with gccgo-7 is: ... <1><3b7>: Abbrev Number: 2 (DW_TAG_subprogram) <3b8> DW_AT_external : 1 <3b8> DW_AT_name : package2.Foo <3bc> DW_AT_decl_file : 1 <3bd> DW_AT_decl_line : 5 <3be> DW_AT_linkage_name: go.package2.Foo <3c2> DW_AT_low_pc : 0x402563 <3ca> DW_AT_high_pc : 0xdc <3d2> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_c= fa) <3d4> DW_AT_GNU_all_tail_call_sites: 1 ... and with gccgo-11: ... <1><1b9e>: Abbrev Number: 10 (DW_TAG_subprogram) <1b9f> DW_AT_external : 1 <1b9f> DW_AT_name : go.package2.Foo <1ba3> DW_AT_decl_file : 1 <1ba4> DW_AT_decl_line : 5 <1ba5> DW_AT_decl_column : 1 <1ba6> DW_AT_linkage_name: go_0package2.Foo <1baa> DW_AT_low_pc : 0x403857 <1bb2> DW_AT_high_pc : 0x86 <1bba> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_c= fa) <1bbc> DW_AT_GNU_all_tail_call_sites: 1 ... Note how DW_AT_name has changed, to include a "go." extra prefix. And that the linkage name has changed due to v3 mangling (see PR27238). But the same problem occurs. Without the (for now unposted) fix for PR27238, we have: ... (gdb) p symbols.empty () $1 =3D true (gdb) p minimal_symbols.empty () $2 =3D true ... and with the fix: ... (gdb) p symbols.empty () $3 =3D true (gdb) p minimal_symbols.empty () $4 =3D false ... And for -ex "break go.package2.Foo", we have with and without the fix: ... (gdb) p symbols.empty () $1 =3D true (gdb) p minimal_symbols.empty () $2 =3D true ... Again the correct symbol table is expanded. Looking at the symbol table: ... void go_0package2.Foo(void); block object 0x3c1eb30, 0x403857..0x4038dd section .text package2; block #001, object at 0x3c1ec60 under 0x3c1ed00, 5 symbols in 0x403857..0x4038dd typedef int64 int;=20 typedef int64 int64;=20 const struct { uint8 *__data; int __length; } go..C6; static at 0x405020 section .rodata typedef struct { uint8 *__data; int __length; } string;=20 typedef uint8 uint8;=20 block #002, object at 0x3c1eb30 under 0x3c1ec60, 0 symbols in 0x403857..0x4038dd, function go_0package2.Foo, go_0package2.Foo ... it's clear that the symbol table holds the mangled name. That matches with the store_sym_names_in_linkage_form_p setting, but I'm guessing we do the lookup with the demangled name. --=20 You are receiving this mail because: You are on the CC list for the bug.=