Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
arthurzam opened this issue Feb 27, 2023 · 7 comments
Open

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

arthurzam opened this issue Feb 27, 2023 · 7 comments
Labels
arch-arm64 NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@arthurzam
Copy link

arthurzam commented Feb 27, 2023 •
edited

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
Copy link
Contributor

CC @ianlancetaylor, @cherrymui.

@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-arm64 labels Feb 27, 2023
@dmitshur dmitshur added this to the Backlog milestone Feb 27, 2023
@thesamesam
Copy link

Might be related to an old bug? #39466

@ianlancetaylor
Copy link
Contributor

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
Copy link
Member

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
Copy link

thesamesam commented Feb 27, 2023 •
edited

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
Copy link
Member

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
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch-arm64 NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@arthurzam @dmitshur @ianlancetaylor @thesamesam @cherrymui