runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support

[bradfitz]

--- FAIL: TestGdbPython (0.30s)
    runtime-gdb_test.go:50: gdb version 7.7
    runtime-gdb_test.go:152: package testing source file: /tmp/workdir/go/src/testing/testing.go
    runtime-gdb_test.go:153: failed to load Go runtime support: "/tmp/go-build613978241/a.exe": not in executable format: File format not recognized
        "/tmp/go-build613978241/a.exe": not in executable format: File format not recognized
        No auto-load scripts.
        No symbol table is loaded.  Use the "file" command.
        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
        No executable file specified.
        Use the "file" or "exec-file" command.
        BEGIN info goroutines
        Undefined info command: "goroutines".  Try "help info".
        END
        No stack.
        BEGIN print mapvar
        No symbol table is loaded.  Use the "file" command.
        END
        BEGIN print strvar
        No symbol table is loaded.  Use the "file" command.
        END
        No stack.
        BEGIN goroutine 2 bt
        Undefined command: "goroutine".  Try "help".
        END
--- FAIL: TestGdbBacktrace (0.15s)
    runtime-gdb_test.go:50: gdb version 7.7
    runtime-gdb_test.go:264: could not find '#0.*main\.eee' in backtrace
    runtime-gdb_test.go:265: gdb output:
        "/tmp/go-build806889452/a.exe": not in executable format: File format not recognized
        No symbol table is loaded.  Use the "file" command.
        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
        No executable file specified.
        Use the "file" or "exec-file" command.
        No stack.
        The program is not being run.
FAIL
FAIL    runtime 14.687s

I propose we skip these tests there for now so we can see what else is failing. (These tests already skip if gdb is absent anyway)

/cc @dr2chase

[gopherbot]

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

[rsc]

I believe ppc64 (big endian) is essentially unsupported. Unless the problem also manifests on ppc64le, I think this is unplanned work.

[bcmills]

Unless the problem also manifests on ppc64le, I think this is unplanned work.

Here's a flake observed on linux/ppc64le. Same test, but a different failure mode. https://build.golang.org/log/0c0a8553ebc6c605bd20ed1fd8ec44b81e2575e1.

``` ##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick --- FAIL: TestGdbPython (0.57s) runtime-gdb_test.go:66: gdb version 7.7 runtime-gdb_test.go:213: gdb output: Loading Go Runtime support. Loaded Script Yes /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/runtime-gdb.py Breakpoint 1 at 0x9333c: file /tmp/go-build160953289/main.go, line 15. hi Breakpoint 1, main.main () at /tmp/go-build160953289/main.go:17 17 gslice = slicevar BEGIN info goroutines * 1 running syscall.Syscall 2 runnable runtime.forcegchelper 17 waiting runtime.gopark 18 runnable runtime.runfinq END BEGIN print mapvar $1 = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"} END BEGIN print strvar $2 = "abc" END BEGIN info locals mapvar = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"} strvar = "abc" slicevar = []string END BEGIN goroutine 1 bt #0 main.main () at /tmp/go-build160953289/main.go:17 END BEGIN goroutine 2 bt #0 runtime.forcegchelper () at /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/proc.go:242 #1 0x000000000009333c in fmt.Println (a=..., n=, err=...) at /tmp/workdir-host-linux-ppc64le-osu/go/src/fmt/print.go:275 #2 main.main () at /tmp/go-build160953289/main.go:14 Traceback (most recent call last): File "/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/runtime-gdb.py", line 536, in invoke gdb.parse_and_eval('$sp = $save_sp') gdb.error: Attempt to assign to an unmodifiable value. Error occurred in Python command: Attempt to assign to an unmodifiable value. END Breakpoint 2 at 0x93370: file /tmp/go-build160953289/main.go, line 18. runtime: newstack sp=0xc000032fc0 stack=[0xc000064000, 0xc000065000] morebuf={pc:0x9333c sp:0xc000032fc0 lr:0x0} sched={pc:0x39424 sp:0xc000032fc0 lr:0x9333c ctxt:0x0} runtime: gp=0xc000000180, goid=1, gp->status=0x2 runtime: split stack overflow: 0xc000032fc0 < 0xc000064000 fatal error: runtime: split stack overflow runtime stack: runtime.throw(0xd4daa, 0x1d) /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/panic.go:608 +0x5c runtime.newstack() /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/stack.go:995 +0x7a4 runtime.morestack() /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/asm_ppc64x.s:339 +0x60 goroutine 1 [running]: runtime.forcegchelper() /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/proc.go:242 +0x14 fp=0xc000032fc0 sp=0xc000032fc0 pc=0x39424 runtime: unexpected return pc for main.main called from 0x0 stack: frame={sp:0xc000032fc0, fp:0xc000033080} stack=[0xc000064000,0xc000065000) fmt.Println(...) /tmp/workdir-host-linux-ppc64le-osu/go/src/fmt/print.go:275 main.main() /tmp/go-build160953289/main.go:14 +0x1ec fp=0xc000033080 sp=0xc000032fc0 pc=0x9333c [Inferior 1 (process 12962) exited with code 02] BEGIN goroutine 1 bt at the end No such goroutine: 1 END runtime-gdb_test.go:286: goroutine 1 bt at the end failed: No such goroutine: 1 FAIL FAIL runtime 34.375s ```

[bcmills]

Never mind, that one seems to be #28679.

[laboger]

linux/ppc64 does not support cgo. The reason this test fails on linux/ppc64 is that it tries to build a program to be debugged with gdb, but the program uses cgo so cannot be built. The failure has nothing to do with gdb.

If you use a program that can be built with linux/ppc64, gdb and the gdb python scripts should work on linux/ppc64 as well as linux/ppc64le. Everything that gdb looks at (the stack, register usage, threads and goroutines) should be the same between linux/ppc64 and linux/ppc64le.

I tried gdb on a simple hello.go test and things worked fine:

Breakpoint 1 at 0x94680: file /home/boger/gotests/hello.go, line 8.
(gdb) run
Starting program: /home/boger/gotests/hello 
[New LWP 5583]
[New LWP 5584]
[New LWP 5585]
[New LWP 5586]
[New LWP 5587]

Thread 1 "hello" hit Breakpoint 1, fmt.Printf (format=..., a=..., n=<optimized out>, err=...)
    at /home/boger/golang/go/src/fmt/print.go:208
208     return Fprintf(os.Stdout, format, a...)
(gdb) info goroutines
* 1 running  runtime.systemstack_switch
  2 waiting  runtime.gopark
  17 waiting  runtime.gopark
  18 waiting  runtime.gopark
(gdb) goroutine 1 bt
#0  fmt.Printf (format=..., a=..., n=<optimized out>, err=...) at /home/boger/golang/go/src/fmt/print.go:208
#1  main.main () at /home/boger/gotests/hello.go:8
(gdb) goroutine 2 bt
#0  runtime.gopark (unlockf=<optimized out>, lock=0x173b50 <runtime.forcegc>, reason=16 '\020', traceEv=20 '\024', 
    traceskip=1) at /home/boger/golang/go/src/runtime/proc.go:302
#1  0x00000000000392d4 in runtime.goparkunlock (reason=<optimized out>, traceEv=<optimized out>, 
    traceskip=<optimized out>, lock=<optimized out>) at /home/boger/golang/go/src/runtime/proc.go:307
#2  runtime.forcegchelper () at /home/boger/golang/go/src/runtime/proc.go:250
#3  0x0000000000060bc4 in runtime.goexit () at /home/boger/golang/go/src/runtime/asm_ppc64x.s:857
Backtrace stopped: frame did not save the PC

[bradfitz]

Thanks. Retitled this bug.

[laboger]

Actually I just got on a system where gdb was at a high enough level and removed the check to skip tests on linux/ppc64, and found that those tests that need cgo are skipped if cgo is not enabled. And those that don't need it pass. I can submit the change if you want it now.

[laboger]

Oh, the builder has to have at least gdb 7.7 or the tests in question are skipped.