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

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

Closed
RustyDust opened this issue Mar 15, 2021 · 13 comments
Closed

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

RustyDust opened this issue Mar 15, 2021 · 13 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@RustyDust
Copy link

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.
@RustyDust RustyDust mentioned this issue Mar 15, 2021
Closed
@gopherbot
Copy link

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

@agnivade
Copy link
Contributor

/cc @thanm @jeremyfaller

@thanm
Copy link
Contributor

thanm commented Mar 15, 2021

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

@RustyDust
Copy link
Author

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

thanm commented Mar 15, 2021

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

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

thanm commented Mar 15, 2021

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 cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 15, 2021
@cherrymui cherrymui added this to the Unplanned milestone Mar 15, 2021
@cherrymui
Copy link
Member

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

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

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

@dididudu998
Copy link

dididudu998 commented Mar 17, 2021 •
edited

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.

@cherrymui
Copy link
Member

@dididudu998 this looks like a different problem. Could you file a new issue? It would be helpful if you provide what command you run and the full error output. If possible, do go build -x -ldflags=-v to get more information, which could be helpful.

@ppenguin
Copy link

ppenguin commented Feb 2, 2022

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.

@RustyDust (posting for posterity): your patch applied to 1.17.6 (in my fork) appears to build nicely. (I got the segfault when compiling packr2 for an ancient NAS target based on glibc-2.13 in a container with the standard go1.17.2-arm release, that's my reason to need a patched go).
The tests fail though, but I'll first test using it for my builds and see what happens.

@golang golang locked and limited conversation to collaborators Feb 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

Successfully merging a pull request may close this issue.

cmd/link: bring back R_ARM_V4BX for Annapurna AL-212 and possibly others
7 participants
@RustyDust @agnivade @gopherbot @dididudu998 @thanm @cherrymui @ppenguin