misc/cgo/test: link failure with atomics on arm64

[arthurzam]

What version of Go are you using (go version)?

$ go version
go version go1.19.6 linux/arm64

Does this issue reproduce with the latest release?

Yes, with 1.20.1

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/var/tmp/portage/dev-lang/go-1.19.6/work/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/var/tmp/portage/dev-lang/go-1.19.6/work/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.19.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/var/tmp/portage/dev-lang/go-1.19.6/work/go/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2755505689=/tmp/go-build -gno-record-gcc-switches"

• gcc (Gentoo 12.2.1_p20230121-r1 p10) 12.2.1 20230121
• Linux arm64-stable 5.15.64-gentoo-dist aarch64 GNU/Linux

What did you do?

On an arm64 machine, I've used previous bootstrap of 1.19.5 (located at /usr/lib/go, had passed the tests) and compiled and ran the test suite:

1. cd src
2. GOROOT_BOOTSTRAP=/usr/lib/go GOOS=linux GOARCH=arm64 ./make.bash
3. PATH="$(dirname ${PWD})/bin:${PATH}" ./run.bash -no-rebuild

What did you expect to see?

Test suite passing as with previous version 1.19.5

What did you see instead?

Test suite failure

##### ../misc/cgo/test
ok      misc/cgo/test   2.016s
# misc/cgo/test.test
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_mulsc3.o/): 147259: sym#128 (wm4.0.2dd2ef601d1ee34f25664efd3ab09129): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_muldc3.o/): 147264: sym#128 (wm4.0.04c8e0a7cf24532cc22a8c08a8485b50): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_absvsi2.o/): 147269: sym#127 (wm4.0.8b6811288dcbb7bf8d7935a4ff231675): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(lse-init.o/): 147281: sym#26 (wm4.0.e9dbc2a4f4cd55ed8d876963f7cda273): ignoring symbol in section 1 (type 0)
misc/cgo/test(.text): unknown symbol __mulsc3 in callarm64
misc/cgo/test(.text): unknown symbol __muldc3 in callarm64
misc/cgo/test(.text): unknown symbol __absvsi2 in callarm64
libgcc(.text): unknown symbol __aarch64_have_lse_atomics
misc/cgo/test(.text): relocation target __mulsc3 not defined
misc/cgo/test(.text): relocation target __muldc3 not defined
misc/cgo/test(.text): relocation target __absvsi2 not defined
libgcc(.text): relocation target __aarch64_have_lse_atomics not defined
FAIL    misc/cgo/test [build failed]
FAIL
2023/02/27 20:06:52 Failed: exit status 2
ok      misc/cgo/test   2.084s
ok      misc/cgo/testtls        0.004s
ok      misc/cgo/testtls        0.005s

The environment where this happened is inside a container, so I can perform extra check or info collection if requested.

[dmitshur]

CC @ianlancetaylor, @cherrymui.

[thesamesam]

Might be related to an old bug? #39466

[ianlancetaylor]

Just a note that this is specifically running misc/cgo/test with -linkmode=internal.

Looks like for #39466 we disabled this test on arm64. Then in https://go.dev/cl/404296 Cherry fixed the handling of hidden symbols such that internal linking worked again on arm64. But now it is broken again and someone will have to figure out why.

Note that this does not affect anybody using Go, unless they are explicitly using -ldflags=-linkmode=internal. It would be fine to just disable the test again. But it's worth finding out why it stopped working.

[cherrymui]

loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_mulsc3.o/): 147259: sym#128 (wm4.0.2dd2ef601d1ee34f25664efd3ab09129): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_muldc3.o/): 147264: sym#128 (wm4.0.04c8e0a7cf24532cc22a8c08a8485b50): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(_absvsi2.o/): 147269: sym#127 (wm4.0.8b6811288dcbb7bf8d7935a4ff231675): ignoring symbol in section 1 (type 0)
loadelf: /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a(lse-init.o/): 147281: sym#26 (wm4.0.e9dbc2a4f4cd55ed8d876963f7cda273): ignoring symbol in section 1 (type 0)

It looks to me that these object files are supposed to provide the missing symbols (__mulsc3, __aarch64_have_lse_atomics, etc.), but the object loader probably stopped early due to unable to handle these wm4 symbols. Do you know what these symbols are? What compiler flags are used to build libgcc.a? Thanks.

[thesamesam]

We've not intentionally done anything interesting here, only boring normal flags (-O2 -pipe):

sys-devel/gcc-12.2.1_p20230121-r1::gentoo was built with the following:
USE="(cxx) fortran nls nptl openmp (pie) sanitize ssp (-ada) (-cet) (-custom-cflags) -d -debug -default-stack-clash-protection -default-znow -doc (-fixed-point) -go -graphite (-hardened) (-ieee-long-double) -jit (-libssp) -lto (-multilib) -objc -objc++ -objc-gc (-pch) -pgo -systemtap -test (-valgrind) -vanilla -vtv -zstd"
CFLAGS="-pipe -O2"
CXXFLAGS="-pipe -O2"

Interestingly:

# nm /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a 2>/dev/null | grep __aarch64_have_lse_atomics | sort -u
                 U __aarch64_have_lse_atomics # lots of these lines, filtered out by sort -u
0000000000000000 B __aarch64_have_lse_atomics
# nm /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a 2>/dev/null | grep -i mulsc3
_mulsc3.o:
0000000000000000 T __mulsc3

(We've had an odd bug reported in Gentoo before at https://bugs.gentoo.org/868018 but only for GCC 11, while this is GCC 12, and our GCC 12 doesn't exhibit the issue discussed in that bug, so it might not be related. Just thought I'd mention it on the off chance.)

[cherrymui]

Could you share the nm output without grepping specific symbols? I'd be interested to see if there is any other symbol in _mulsc3.o (or any of the objects mentioned above). I'd guess there is, which the linker doesn't handle.
Would it be convenient to share the object file? Thanks.

[thesamesam]

• nm /usr/lib/gcc/aarch64-unknown-linux-gnu/12/libgcc.a output: nm.txt
• libgcc.a.gz