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

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

[vries at gcc dot gnu.org]

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

            Bug ID: 30941
           Summary: [gdb/go] cannot find package2.Foo in expanded symtab
                    containing go.package2.Foo
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: go
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

While investigating PR27238, I found that when not generating dwarf info:
...
$ gccgo-7 ./src/gdb/testsuite/gdb.go/package2.go -c -g0
$ gccgo-7 ./src/gdb/testsuite/gdb.go/package1.go package2.o -g0
$ gdb -q -batch a.out -ex "break package2.Foo"
Breakpoint 1 at 0x402563
...
the breakpoint is set just fine.

When generating dwarf info:
...
$ gccgo-7 ./src/gdb/testsuite/gdb.go/package2.go -c -g
$ gccgo-7 ./src/gdb/testsuite/gdb.go/package1.go package2.o -g
$ gdb -q -batch a.out -ex "break package2.Foo"
Breakpoint 1 at 0x402563: file ./src/gdb/testsuite/gdb.go/package2.go, line 5.
...
we get line info in addition, but the dwarf is not actually used to find the
function address.

I only found this out during debugging, I didn't find a good way to demonstrate
it otherwise:
...
(gdb) fin
Run till exit from #0  find_linespec_symbols (state=0x7fffffffcd10, 
    file_symtabs=std::vector of length 1, capacity 1 = {...},
    lookup_name=0x370a770 "package2.Foo", 
    name_match_type=symbol_name_match_type::WILD,
    symbols=0x7fffffffc980,
    minsyms=0x7fffffffc960)
    at /data/vries/gdb/src/gdb/linespec.c:3814
linespec_parse_basic (parser=0x7fffffffcce0) at linespec.c:1822
1822          if (!symbols.empty () || !minimal_symbols.empty ())
(gdb) p symbols.empty ()
$1 = true
(gdb) p minimal_symbols.empty ()
$2 = false
...

The expansion of the symtab seems to be happening, but the following search in
the expanded symtab fails to return anything.

My guess is that package2.Foo fails to match on go.package2.Foo:
...
block #000, object at 0x476a640, 2 symbols in 0x402563..0x40263f
 void go.package2.Foo(void); block object 0x476a4c0, 0x402563..0x40263f section
.text
 package2;

  block #001, object at 0x476a5f0 under 0x476a640, 0 symbols in
0x402563..0x40263f
    block #002, object at 0x476a4c0 under 0x476a5f0, 0 symbols in
0x402563..0x40263f, function go.package2.Foo, go.package2.Foo
...

I tried the same with -ex "break go.package2.Foo", and in that case gdb does
manage to find it in the expanded symtab.

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

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

[vries at gcc dot gnu.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.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3f577261903d4558451b005bbfee03fcdbb1d570

commit 3f577261903d4558451b005bbfee03fcdbb1d570
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Oct 5 23:22:11 2023 +0200

    [gdb/go] Handle v3 go_0 mangled prefix

    With gcc-10 we have:
    ...
    (gdb) break package2.Foo^M
    Breakpoint 2 at 0x402563: file package2.go, line 5.^M
    (gdb) PASS: gdb.go/package.exp: setting breakpoint 1
    ...
    but with gcc-11:
    ...
    gdb) break package2.Foo^M
    Function "package2.Foo" not defined.^M
    Make breakpoint pending on future shared library load? (y or [n]) n^M
    (gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at
package2.Foo
    ...

    In the gcc-10 case, though the exec contains dwarf, it's not used to set
the
    breakpoint (which is an independent problem, filed as PR go/30941), instead
    the minimal symbol information is used.

    The minimal symbol information changed between gcc-10 and gcc-11:
    ...
    $ nm a.out.10 | grep Foo
    000000000040370d T go.package2.Foo
    0000000000404e50 R go.package2.Foo..f
    $ nm a.out.11 | grep Foo
    0000000000403857 T go_0package2.Foo
    0000000000405030 R go_0package2.Foo..f
    ...

    A new v3 mangling scheme was used.  The mangling schemes define a separator
    character and mangling character:
    - for v2, dot is used both as separator character and mangling character,
and
    - for v3, dot is used as separator character and underscore as mangling
      character.

    For more details, see [1] and [2].

    In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler,
libgo:
    change mangling scheme"), function Special_char_code::Special_char_code. ]

    Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the
    test-case.

    Note that this doesn't fix this regression:
    ...
    $ gccgo-10 package2.go -c -g0
    $ gccgo-10 package1.go package2.o -g0
    $ gdb -q -batch a.out -ex "break go.package2.Foo"
    Breakpoint 1 at 0x40370d
    $ gccgo-11 package2.go -c -g0
    $ gccgo-11 package1.go package2.o -g0
    $ gdb -q -batch a.out -ex "break go.package2.Foo"
    Function "go.package2.Foo" not defined.
    ...

    With gcc-10, we set a breakpoint on the mangled minimal symbol.  That
    one has simply changed for gcc-11, so it's equivalent to using:
    ...
    $ gdb -q -batch a.out -ex "break go_0package2.Foo"
    Breakpoint 1 at 0x403857
    ...
    which does work.

    Tested on x86_64-linux:
    - openSUSE Leap 15.4, using gccgo-7,
    - openSUSE Tumbleweed, using gccgo-13.

    PR go/27238
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238

    [1] https://go-review.googlesource.com/c/gofrontend/+/271726
    [2] https://github.com/golang/go/issues/41862#issuecomment-707244103

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