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=<optimized out>, 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.