cmd/link: panic on riscv64 with CGO enabled due to empty container symbol

[imguoguo]

Go version

go version go1.24.1 linux/riscv64

Output of go env in your module/workspace:

AR='ar'                                                                                                                                                  
CC='gcc'
CGO_CFLAGS='-gdwarf-5 -O2'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='riscv64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/builddir/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/builddir/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build74935071=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='riscv64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/builddir/build/BUILD/golang-1.24.1-build/go/src/go.mod'
GOMODCACHE='/builddir/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/builddir/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn'
GORISCV64='rva20u64'
GOROOT='/builddir/build/BUILD/golang-1.24.1-build/go'
GOSUMDB='off'
GOTELEMETRY='local'
GOTELEMETRYDIR='/builddir/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/builddir/build/BUILD/golang-1.24.1-build/go/pkg/tool/linux_riscv64'
GOVCS=''
GOVERSION='go1.24.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Built Go (version 1.24.1) on a riscv64 system on Fedora 42 with CGO enabled. Ran the full Go check suite and also attempted a minimal reproduction by isolating tests in the internal/poll directory. In the minimal test setup, I removed others test files in internal/poll and only the test files error_linux_test.go, error_stub_test.go, and error_test.go remained. Furthermore, I experimented with a workaround by commenting out the following code in error_test.go:

import (
        "fmt"
        "io/fs"
//      "net"
        "os"
)

// ...

// if nerr, ok := err.(*net.OpError); ok {
//     err = nerr.Err
// }

and trying to run

cd /builddir/build/BUILD/golang-1.24.1-build/go/src
./run.bash  --no-rebuild -v -v -v -k internal/poll

What did you see happen?

The build fails during the linking phase with a panic. Key parts of the error log include:

panic: unexpected empty container symbol

loadelf: $WORK/b304/_pkg_.a(_x001.o): 183065: sym#47 (".LVUS0"): ignoring symbol in section 8 (".debug_loclists") (type 0)
...

This panic in the linker (cmd/link/internal/loader.(*Loader).AddInteriorSym) prevents the test suite from completing. The workaround of commenting out the code in error_test.go allowed the tests to pass, indicating that the issue might be related to the handling of certain symbols.

And I also tried with CGO disabled(by set CGO_ENABLED=0), test complete successfully without panics.

full build log: http://openkoji.iscas.ac.cn/kojifiles/work/tasks/8787/7038787/build.log
golang spec file: https://src.fedoraproject.org/rpms/golang/blob/rawhide/f/golang.spec

What did you expect to see?

I expected the Go build and test suite to complete successfully without panics, even with CGO enabled on the riscv64 platform. The behavior should be consistent with other architectures where the build passes without the need to modify test files.

[imguoguo]

cc @golang/riscv64

[dr2chase]

When you say "handling of certain symbols", is it possible to be more specific?

[dr2chase]

@golang/compiler

[cherrymui]

sym#47 (".LVUS0"): ignoring symbol in section 8 (".debug_loclists") (type 0)

Reading the error message, it looks like the error is from loading a symbol from an empty section in a C object. Perhaps we should just ignore it, especially that it is not a loadable section. Perhaps we can ignore the entire debug sections from C object?

@thanm do you know if we use the debug info from C objects in internal linking mode? I think we probably don't. (It may be a good thing to do for the future. But that needs a good amount of effort beyond just loading the symbols. If currently we load the symbols but not doing anything with them, we may as well not load them at all.)

[thanm]

@thanm do you know if we use the debug info from C objects in internal linking mode? I think we probably don't. (It may be a good thing to do for the future. But that needs a good amount of effort beyond just loading the symbols. If currently we load the symbols but not doing anything with them, we may as well not load them at all.)

From looking at the code, it does appear that we're loading up .debug_* sections in the host object loader but then never integrating them into the final debug gen, which I agree is not ideal.