[Bug go/27238] New: [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[Bug go/27238] New: [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

            Bug ID: 27238
           Summary: [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint
                    at 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: ---

With gcc-11 I run into:
...
(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: setting breakpoint at package2.Foo
...

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Difference in minimal symbols:
...
$ nm package.10 | grep Foo
000000000040374d T go.package2.Foo
0000000000404e70 R go.package2.Foo..f
$ nm package.11 | grep Foo
00000000004038e6 T go_0package2.Foo
0000000000405090 R go_0package2.Foo..f
...

And in .debug_info:
...
$ readelf -w package.10 | grep Foo  
    <1d8d>   DW_AT_name        : package2.Foo
    <1d94>   DW_AT_linkage_name: go.package2.Foo
$ readelf -w package.11 | grep Foo 
    <1750>   DW_AT_name        : go.package2.Foo
    <1757>   DW_AT_linkage_name: go_0package2.Foo
...

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13156
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13156&action=edit
package exec with gcc 10, gzipped

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13157
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13157&action=edit
package exec with gcc 11, gzipped

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I ran into this too.  The DWARF also has these names:

 <1><163e>: Abbrev Number: 10 (DW_TAG_subprogram)
    <163f>   DW_AT_external    : 1
    <163f>   DW_AT_name        : (indirect string, offset: 0xd69):
go.package2.Foo
    <1643>   DW_AT_decl_file   : 1
    <1644>   DW_AT_decl_line   : 5
    <1645>   DW_AT_decl_column : 1
    <1646>   DW_AT_linkage_name: (indirect string, offset: 0xdd8):
go_0package2.Foo
    <164a>   DW_AT_low_pc      : 0x40420a
    <1652>   DW_AT_high_pc     : 0x99
    <165a>   DW_AT_frame_base  : 1 byte block: 9c       (DW_OP_call_frame_cfa)
    <165c>   DW_AT_call_all_tail_calls: 1


So maybe the mangling changed and gdb needs to change as well?

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
The dup points to this:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan at jankratochvil dot net

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
*** Bug 17517 has been marked as a duplicate of this bug. ***

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
With this patch:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 5bbc8e24cf9..c4c3afd0141 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -7142,6 +7142,18 @@ dwarf2_physname (const char *name, struct die_info *die,
struct dwarf2_cu *cu)
       if (cu->language_defn->store_sym_names_in_linkage_form_p ())
        {
          /* Do nothing (do not demangle the symbol name).  */
+         if (cu->lang () == language_go)
+           {
+             char *s;
+             if (startswith (mangled, "go_0"))
+               {
+                 s = strdup (mangled + 1);
+                 s[0] = 'g';
+                 s[1] = 'o';
+                 s[2] = '.';
+                 demangled.reset (s);
+               }
+           }
        }
       else
        {
...
I manage to do:
...
$ gdb -q -batch package -ex "b go.package2.Foo" 
Breakpoint 1 at 0x404228: file package2.go, line 5.
...

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
This is about supporting v3 mangling, introduced in gcc 11:
...
commit a01dda3c23b836754814fab1cab949a1bbc641e8
Author: Ian Lance Taylor <iant@golang.org>
Date:   Mon Nov 16 20:06:53 2020 -0800

    compiler, libgo: change mangling scheme

    Overhaul the mangling scheme to avoid ambiguities if the package path
    contains a dot. Instead of using dot both to separate components and
    to mangle characters, use dot only to separate components and use
    underscore to mangle characters.

    For golang/go#41862

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
...

Difference in style:
...
+       // Original mangling: go.l__ufer.Run
+       // Mangling v2: go.l..u00e4ufer.Run
+       // Mangling v3: go_0l_u00e4ufer.Run
...

Explained in more detail in
https://github.com/golang/go/issues/41862#issuecomment-707244103 (second path
case was chosen, AFAICT).

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> Difference in style:
> ...
> +       // Original mangling: go.l__ufer.Run
> +       // Mangling v2: go.l..u00e4ufer.Run
> +       // Mangling v3: go_0l_u00e4ufer.Run
> ...
> 

Coming from the source code:
...
// mangleCheckCode is the package we compile to determine the mangling scheme.
const mangleCheckCode = `
package läufer
func Run(x int) int {
  return 1
}
`
...

> Explained in more detail in
> https://github.com/golang/go/issues/41862#issuecomment-707244103 (second
> path case was chosen, AFAICT).

What I still don't get though is why we have go_0l_u00e4ufer.Run.  Based on the
description of v3, I would have expected "go.l_u00e4ufer.Run", in other words,
3 components: go, läufer and Run, but go_0l_u00e4ufer.Run describes two
components: go.läufer and Run.

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor <ian at airs dot com> ---
For a simple function like Run in this example, the name has two components:
the package-path and the name.  The symbol is the encoded package-path,
followed by ".", followed by the encoded name.

In normal usage, when building with "go build", GCC is invoked with a
-fgo-pkgpath option that sets the package path.  This will be based on the
module name and the package name.  When gccgo is invoked with the -fgo-pkgpath
option (or the older -fgo-prefix option) then the pkgpath will be the string
"go." (with a trailing period) followed by the package name that appears in the
source code.  In this case the package name in the source code is "läufer", so
the package-path is "go.läufer".  The "." is encoded as "_0", the "ä" is
encoded as "_u00e4", hence the encoded package-path is "go_0l_u00e4ufer".

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor <ian at airs dot com> ---
(In reply to Ian Lance Taylor from comment #10)
>
> When gccgo is invoked with the

Sorry, s/with/without/

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
Interesting find: when running with gccgo-7, the test-case passes.  But it
finds the function it breaks on in the minimal symbols, not the dwarf.

So this works fine, it just doesn't print the line 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 "b package2.Foo" -ex "b go.package2.Foo"
Breakpoint 1 at 0x402563
Breakpoint 2 at 0x402563
...

But with gccgo-11 it doesn't work:
...
$ gccgo-11 ./src/gdb/testsuite/gdb.go/package2.go -c -g0
$ gccgo-11 ./src/gdb/testsuite/gdb.go/package1.go package2.o -g0
$ gdb -q -batch a.out -ex "b package2.Foo" -ex "b go.package2.Foo"
Function "package2.Foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
Function "go.package2.Foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
...

So it looks like the regression is in minimal symbol handling, dwarf already
wasn't working in the first place.

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #12)
> Interesting find: when running with gccgo-7, the test-case passes.  But it
> finds the function it breaks on in the minimal symbols, not the dwarf.

  ...

> So it looks like the regression is in minimal symbol handling, dwarf already
> wasn't working in the first place.

Filed PR30941 about the dwarf bit.

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2023-October/203003.html

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

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 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.

[Bug go/27238] [gcc-11] FAIL: gdb.go/package.exp: setting breakpoint at package2.Foo

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #16 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

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