cmd/ld: do we still need runtime-gdb.py? #6963
Labels
Milestone
Comments
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. |
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 ---- |
Attaching diff that will be proposed if there is interest. Attachments:
|
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. |
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/ |
|
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 |
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. |
I edited debugging_with_gdb.html to reflect how things work now: https://golang.org/cl/69870049 |
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. |
CL https://golang.org/cl/87870048 mentions this issue. |
|
This issue was closed by revision dacc020. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
(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?The text was updated successfully, but these errors were encountered: