cmd/link: 1.16 broken for Annapurna AL-212 and possibly other ARM chips (R_ARM_V4BX)

[RustyDust]

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

Currently I'm using 1.15.8 which I compiled on my Netgear ReadyNAS RN204 that is using an Annapurna AL-212 chip.
When trying to build 1.16.x (tried with 1.16 and 1.16.2) I ran into compile problems, telling me about unexpected relocation type 296 (R_ARM_V4BX)

Does this issue reproduce with the latest release?

Yes.
Inspection of the code in question showed that the linker code handling R_ARM_V4BX was removed between 1.15.x and 1.16.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="arm"
GOBIN=""
GOCACHE="/home/stefan/.cache/go-build"
GOENV="/home/stefan/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/stefan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/stefan/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.15"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.15/pkg/tool/linux_arm"
GOVCS=""
GOVERSION="go1.15.8"
GCCGO="gccgo"
GOARM="5"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/stefan/test/mc/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1804087667=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go-go1.16.2/$ cd src
go-go1.16.2/src$ ./make.bash
Building Go cmd/dist using /usr/lib/go-1.15. (go1.15.8 linux/arm)
Building Go toolchain1 using /usr/lib/go-1.16.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/arm.
net(.text): unexpected relocation type 296 (R_ARM_V4BX)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x115a84]

What did you expect to see?

A working build.

What did you see instead?

Go 1.16 and 1.16.2 won't build, see above.

[gopherbot]

Change https://golang.org/cl/301631 mentions this issue: cmd/link: bring back R_ARM_V4BX for Annapurna AL-212 and possibly others

[agnivade]

/cc @thanm @jeremyfaller

[thanm]

What vintage of C compiler are you using? R_ARM_V4BX as I understand it is an ArmV4 construct (e.g. very ancient).

[RustyDust]

Since the ReadyNAS "firmware" is based on Debian 8 it's gcc 4.7.2 and, yes, that's quite ancient. But I was under the impression that gcc wouldn't be used at all when building with a version of go already present on the system?

[thanm]

Go needs a C compiler in order to support cgo, which is enabled by default. So if you run make.bash at some point the C compiler will get invoked.

You can get the behavior you refer to by using CGO_ENABLED=0 bash make.bash.

[RustyDust]

Thanks, I have to admit that I was mislead by the output from make.bash saying "using /usr/lib/go ..." and thus didn't look further. Now, using CGO_ENABLED=0 works for building go itself on my box but what about modules/packages that rely on cgo? I guess they'd still fail without the patch to cmd/link because of gcc producing outdated ARM code?

I'm aware that this is for really ancient systems but then there's a lot of those out there that can't be updated easily to a newer distro base.

[thanm]

Well I think this may be getting into the philosophical realm... I think most would agree that there needs to be some sort of limit on how far back we want to go in terms of supporting older versions of things. It's just a question of where you draw the line IMO.

Generally speaking when making changes to the tools (linker, compiler etc) we want to have regression tests to make sure that new changes don't break existing functionality.

Having code in the linker that is only triggered by an ancient compiler is problematic in that if we wanted to have a test, we'd need to have a builder with a C compiler that produces something that will cause the code to run ... this is obviously how this got broken here in the first place.

[cherrymui]

Go has required ARMv5+ since a long time ago. I don't think we'll add ARMv4 support back.

If the system and the C toolchain are both ancient, it probably works better with a version of Go that is as ancient. Thanks.

[RustyDust]

I totally agree. As I tried to point out I was under the impression that some part of the go toolchain was responsible for generating the R_ARM_V4BX (stupid in hindsight). That's why I submitted the PR. As long as I can fix it for me using my own patch, I'm fine. Sorry for the troubles.

[cherrymui]

Thanks, @RustyDust . If I read you correctly we can close this. Feel free to reopen if I'm mistaken. Thanks.

[dididudu998]

thought met the same problem:

/usr/local/Cellar/go/1.16.2/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: framework not found CoreFoundation
clang: error: linker command failed with exit code 1 (use -v to see invocation)

the code works in go version 1.15. after upgrade to 1.16.2, error happen.
the code import go-sqlite3, cgo is must option.