[Bug go/30941] [gdb/go] cannot find package2.Foo in expanded symtab containing go.package2.Foo

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
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_cfa)
    <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_cfa)
    <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 = true
(gdb) p minimal_symbols.empty ()
$2 = true
...
and with the fix:
...
(gdb) p symbols.empty ()
$3 = true
(gdb) p minimal_symbols.empty ()
$4 = false
...

And for -ex "break go.package2.Foo", we have with and without the fix:
...
(gdb) p symbols.empty ()
$1 = true
(gdb) p minimal_symbols.empty ()
$2 = 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; 
   typedef int64 int64; 
   const struct {
       uint8 *__data;
       int __length;
   } go..C6; static at 0x405020 section .rodata
   typedef struct {
       uint8 *__data;
       int __length;
   } string; 
   typedef uint8 uint8; 
    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.

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