runtime: TestGdbPython fails when CGO isn't enabled

[nehaljwani]

go version: 1.15.7

$ CGO_ENABLED=0 go test -run=TestGdbPython runtime
--- FAIL: TestGdbPython (0.60s)
    runtime-gdb_test.go:77: gdb version 9.1
    runtime-gdb_test.go:270: gdb output:
        No auto-load scripts.
        Breakpoint 1 at 0x49b498: file /tmp/go-build021787039/main.go, line 26.
        hi
        
        Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/go-build021787039/main.go:26
        26		gslice = slicevar
        BEGIN info goroutines
        Undefined info command: "goroutines".  Try "help info".
        END
        BEGIN print mapvar
        $1 = (map[string]string) 0xc000118f48
        END
        BEGIN print slicemap
        $2 = (map[string][]string) 0xc000110150
        END
        BEGIN print strvar
        $3 = 0x4bf2c1 "abc"
        END
        BEGIN print chanint
        $4 = (chan int) 0xc00013e000
        END
        BEGIN print chanstr
        $5 = (chan string) 0xc000136120
        END
        BEGIN info locals
        mapvar = 0xc000118f48
        chanstr = 0xc000136120
        chanint = 0xc00013e000
        strvar = 0x4bf2c1 "abc"
        slicemap = 0xc000110150
        ptrvar = <optimized out>
        slicevar = {array = 0xc000142000, len = 824634835376, cap = 824634835328}
        END
        BEGIN goroutine 1 bt
        Undefined command: "goroutine".  Try "help".
        END
        BEGIN goroutine all bt
        Undefined command: "goroutine".  Try "help".
        END
        No breakpoint at main.go:15.
        Breakpoint 2 at 0x49b611: file /tmp/go-build021787039/main.go, line 29.
        map[a:[b c d] e:[f g h]], 99, spongepants
        
        Thread 1 "a.exe" hit Breakpoint 2, main.main () at /tmp/go-build021787039/main.go:29
        29	}  // END_OF_PROGRAM
        BEGIN goroutine 1 bt at the end
        Undefined command: "goroutine".  Try "help".
        END

In runtime-gdb_test.go, we have:

        if cgo {
                // When we build the cgo version of the program, the system's
                // linker is used. Some external linkers, like GNU gold,
                // compress the .debug_gdb_scripts into .zdebug_gdb_scripts.
                // Until gold and gdb can work together, temporarily load the
                // python script directly.
                args = append(args,
                        "-ex", "source "+filepath.Join(runtime.GOROOT(), "src", "runtime", "runtime-gdb.py"),
                )
        } else {
                args = append(args,
                        "-ex", "info auto-load python-scripts",
                )
        }

If I remove the if condition and always load src/runtime/runtime-gdb.py , the test passes. But I am not sure if that's the right fix.

[ianlancetaylor]

You deleted the issue without filling it out. Please provide that information. It matters; running

CGO_ENABLED=0 go test -run=TestGdbPython runtime

passes for me, and the first thing we need to do is understand whether I am running it in a similar environment. Thanks.

[nehaljwani]

Here is my go env:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/wani/.cache/go-build"
GOENV="/home/wani/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/wani/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/wani/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/path/to/some/prefix/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/path/to/some/prefix/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="/dev/null"
CXX="/dev/null"
CGO_ENABLED="0"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build882123789=/tmp/go-build -gno-record-gcc-switches"

The go binary itself was built with:

# Disable CGO, and set compilers to /dev/null
export CGO_ENABLED=0
export CC=/dev/null
export CXX=/dev/null
export FC=/dev/null

I'm running this on Fedora 32.

[nehaljwani]

Upgrading from gdb-9.1-6.fc32.x86_64 to gdb-9.1-7.fc32.x86_64 seems to have resolved the issue. Closing.