cmd/ld: do we still need runtime-gdb.py?

[adg]

(Filed under cmd/ld because that's where the reference is.)

As of version 7.5, gdb includes native go support.
However that support is still nascent. From the source of gdb 7.6.2:

/* TODO:
   - split stacks
   - printing of native types
   - goroutines
   - lots more
   - gccgo mangling needs redoing
     It's too hard, for example, to know whether one is looking at a mangled
     Go symbol or not, and their are ambiguities, e.g., the demangler may
     get passed *any* symbol, including symbols from other languages
     and including symbols that are already demangled.
     One thought is to at least add an _G prefix.
   - 6g mangling isn't supported yet
*/

runtime-gdb.py already provides some of this stuff. I'm not sure if this gdb gets in the
way.

We really need to take a look at gdb support before Go 1.3. Does it still work? What's
the recommended usage? And do we need to update the docs?

[minux]

Comment 1:

runtime-gdb.py is broken for at least Go 1.2, also it doesn't work with python 3 binding
of gdb.
That said, I think we still need it even gdb acquired native Go support because gdb
support
for goroutines need internal knowledge of the runtime, and if that support is not
provided
by Go itself, we probably need to wait for next gdb release to debug this release of Go
if
the runtime changes.
Also, for runtime developers, relying only on native gdb support probably means they
don't
support their revised runtime. This is tiny point, because I think runtime developers
rarely
use goroutine support of gdb.
What we should do is add some way to regression test the script, and integrate the test
into the normal builder flow so that the file is kept up-to-date.

[shanemhansen]

Comment 2:

I have a patch to runtime-gdb.py which helps out go1.2 considerably, but is still broken
on tip. Is it worth submitting? It works on go 1.2 using gdb compiled with python 2 and
python 3. pretty printing of slices and maps works.
The $len and $cap function works on slices and maps.
 I'm wondering if this patch is worth submitting for inclusion into a point release of go1.2 and/or a building block for go1.3.
Here's an example:
http://play.golang.org/p/n2L68VzRen
I download as foo.go and build as:
go build foo.go
Here's the output using go1.2 and gdb 7.6 (which is linked against python3) (only
showing relevant portions).
The output is identical for go1.2 and gdb 7.4 (linked against python2.7) because I
adjusted the script to be
more compatible with python 2 and 3.
----
Breakpoint 1, main.main () at /home/shane/foo.go:9
9       fmt.Println("Hello, world", x, y, z)
(gdb) p x
$1 = map[string]string = {["shane"] = "hansen"}
(gdb) p y
$2 =  []int = {1, 2, 3}
(gdb) p z
$3 =  []string = {"shane", "hansen"}
(gdb) p $len(x)
$4 = 1
(gdb) p $len(y)
$5 = 3
(gdb) p $len(z)
$6 = 2
----

[shanemhansen]

Comment 3:

Attaching diff that will be proposed if there is interest.

Attachments:

1. out.diff (2873 bytes)

[josharian]

Comment 4:

Cf also issue #7052, specifically about Python 2/3 compatibility. It looks like your
patch covers slightly different ground than mine
(https://golang.org/cl/47230043). If in fact, runtime-gdb.py is going to live,
we probably want to pull some bit from each of them.
I hit some other bugs in runtime-gdb while starting to test the CL above, but I'm
holding off on reporting them / tracking them down until there's clarity around the
plans here.

[shanemhansen]

Comment 5:

Thanks josharian. I uploaded my changeset as well so it's out there. I'm happy w/
whatever hybrid comes out, or to redo my change on top of yours once it's accepted.
https://golang.org/cl/53590043/

[shanemhansen]

Comment 6:

Just want to add that the current code review is for go 1.2 only. I'm pretty sure it
doesn't work on go tip.
If it is going to go in go1.3 and not a go 1.2 update, we've got more catching up to do.

[rsc]

Comment 7:

This issue was updated by revision f12a167.

Fixes issue #6698
LGTM=rsc
R=golang-codereviews, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/53590043
Committer: Russ Cox 

[grahamking]

Comment 8:

runtime-gdb.py is not used since December 16 2013, this commit:
https://code.google.com/p/go/source/detail?r=5130190e81b59b4734294a979e80ad17ddfc1a10
I tried adding it back in locally, and gdb loads runtime-gdb.py fine, but it doesn't
seem to help. Sample gdb session:
---
(gdb) l
1       package main
2
3       func main() {
4               s := "bob"
5               m := make(map[string]int)
6               m[s] = 42
7               r := make([]int, 3, 10)
8               r[0] = 0
9               r[1] = 1
10              r[2] = 2
(gdb) l
11              println("one")
12              println("two")
13              println("three")
14              println("four")
15      }
(gdb) b 11
Breakpoint 1 at 0x400d3a: file /home/graham/s2.go, line 11.
(gdb) r
Starting program: /home/graham/s2 
Breakpoint 1, main.main () at /home/graham/s2.go:11
11              println("one")
(gdb) p s
No symbol "s" in current context.
(gdb) p r
$1 =  []int = {833357955152, 3, 10, 42, 833358012416, 833357873168, 833357955152, 3}
(gdb) p $len(r)
$2 = 8
(gdb) p m
$3 = map[string]int<error reading variable: Cannot access memory at address 0x13>
(gdb) info goroutines
Python Exception <class 'gdb.error'> Attempt to extract a component of a value
that is not a (null).: 
Error occurred in Python command: Attempt to extract a component of a value that is not
a (null).
---
There's multiple issues with gdb (#7369, #6346, #5552). For 1.3 it might be worth either
removing http://golang.org/doc/gdb, or adding a note that it's in progress.

[grahamking]

Comment 9:

I edited debugging_with_gdb.html to reflect how things work now:
https://golang.org/cl/69870049

[robpike]

Comment 10:

Labels changed: added gdb.

[grahamking]

Comment 11:

To address the original question: "do we still need runtime-gdb.py?"
- runtime-gdb.py has been commented out of tip for 2+ months
- It doesn't do anyting useful if you put it back in (example in my Mar 1 comment, above)
- GDB is not the future for Go
(https://groups.google.com/forum/#!topic/golang-dev/UiVP6F-9-yg/discussion)
That makes me think the answer is No.

[minux]

Comment 12:

I still think the runtime-gdb.py could stay.
for example, it will be of great of help if it can pretty print Go specific
types (maps, for example).
all the other parts could be removed.

[gopherbot]

Comment 13 by erik.westrup:

Could we keep runtime-gdb.py up to date until GDB has the same feature set or we have
another Go-specific debugger?

[gopherbot]

Comment 14:

CL https://golang.org/cl/87870048 mentions this issue.

[rsc]

Comment 15:

This issue was closed by revision dacc020.

Status changed to Fixed.