aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-finishbreakpoint.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2023-10-05 23:22:11 +0200
committerTom de Vries <tdevries@suse.de>2023-10-05 23:22:11 +0200
commit3f577261903d4558451b005bbfee03fcdbb1d570 (patch)
treee8b05dac3d19aca1a324c04a86bdfa7255f9b43b /gdb/python/py-finishbreakpoint.c
parent0b6a94ecbc8b39d6ea86f4337aa23c73a178897e (diff)
downloadgdb-3f577261903d4558451b005bbfee03fcdbb1d570.zip
gdb-3f577261903d4558451b005bbfee03fcdbb1d570.tar.gz
gdb-3f577261903d4558451b005bbfee03fcdbb1d570.tar.bz2
[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
Diffstat (limited to 'gdb/python/py-finishbreakpoint.c')
0 files changed, 0 insertions, 0 deletions