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.

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

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 · 12 comments · May be fixed by #44998
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 · 12 comments · May be fixed by #44998

Comments

@RustyDust
Copy link

@RustyDust RustyDust commented Mar 15, 2021

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 added a commit to RustyDust/go that referenced this issue Mar 15, 2021
When trying to upgrade Go from 1.15.8 to 1.16 on my Netgear ReadyNAS RN204 and
it's Annapurna AL-212 ARM chip I ran into a compile time error:

$ cd src
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]

Inspection of the changes showed that the code for handling R_ARM_V4BX that
was included in 1.15.x is mossing from 1.16 onwards. Since R_ARM_v4BX is
essentially a no-op accoring to the comment in the 1.15 tree I thought it
safe to just let it do that.

Using the patch I was able to build a working go 1.16.2, run the test suite
and build some apps for testing.

However, with me lacking deeper understanding of the code I have no idea
about possible side effects or whether there's an easier way to handle
this. So I'd be more than happy if someone with more knowledge could give
this a look.

Fixes golang#45012
RustyDust added a commit to RustyDust/go that referenced this issue Mar 15, 2021
When trying to upgrade Go from 1.15.8 to 1.16 on my Netgear ReadyNAS RN204 and
it's Annapurna AL-212 ARM chip I ran into a compile time error:

$ cd src
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]

Inspection of the changes showed that the code for handling R_ARM_V4BX that
was included in 1.15.x is mossing from 1.16 onwards. Since R_ARM_v4BX is
essentially a no-op accoring to the comment in the 1.15 tree I thought it
safe to just let it do that.

Using the patch I was able to build a working go 1.16.2, run the test suite
and build some apps for testing.

However, with me lacking deeper understanding of the code I have no idea
about possible side effects or whether there's an easier way to handle
this. So I'd be more than happy if someone with more knowledge could give
this a look.

Fixes golang#45012
@gopherbot
Copy link

@gopherbot gopherbot commented Mar 15, 2021

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

@agnivade agnivade commented Mar 15, 2021

@thanm
Copy link
Member

@thanm 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

@RustyDust RustyDust commented Mar 15, 2021

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
Member

@thanm 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

@RustyDust RustyDust commented Mar 15, 2021

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
Member

@thanm 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 this to the Unplanned milestone Mar 15, 2021
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 15, 2021

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

@RustyDust RustyDust commented Mar 15, 2021

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
Contributor

@cherrymui cherrymui commented Mar 15, 2021

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

@cherrymui cherrymui closed this Mar 15, 2021
@dididudu998
Copy link

@dididudu998 dididudu998 commented Mar 17, 2021

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
Contributor

@cherrymui cherrymui commented Mar 17, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants