-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/link: internal linker fails to build openshift/installer with "program too large, call relocation distance" and segfaults on linux/arm64 #40492
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
Comments
How big are we talking? If you compile it for amd64 how larger is the image? |
@davecheney ~436MB executable on arm64 with external linker, with defaults 468MB on amd64 |
That’s staggering. I thought hyperkube was large. |
TBH same here, assumed it will be in the "normal" ~100MB range, not 3-4 times larger. |
To note it is not stripped with DWARF. And disabling the DWARF have no effect on the build success. |
@gopherbot remove WaitingForInfo |
Also cc @jeremyfaller . Looks like we may have a trampoline insertion issue? |
Note that this was also present in 1.14 and 1.13, so this isn't a regression. I've tentatively put this in the 1.15 milestone, but we probably won't fix this for the initial release (it may make a point release). |
We don't have trampoline support on ARM64. We could implement it (which shouldn't be too hard). But probably too late for 1.15. |
DWARF does not matter. It is solely about program text. |
@cherrymui yeah, it would have been really weird if that had any impact @aclements it would be cool to have it fixed in the go1.15, but it seems that the GC with external linker is ok atm(in all upstream supported versions of GC). So this doesn't seem to me as really critical issue atm. |
Thanks for the follow-up. Since 1.15 is just about out the door at this point, I'll move this to 1.16. |
There is a bug with the golang internal linker for the linux/arm64 target that has yet to be fixed: golang/go#40492
And bumping to 1.17. We should add trampolines, since this is likely to become a problem for more users in the future. |
For the record this is still issue. There are no changes with go1.16. External linker workaround still holds. |
Yes, no work is done for this in Go 1.16. My plan is to do this in 1.17. |
If no one plans to do this next quarter, I am happy to take it. Thank you. |
I plan to do this in 1.17. But if you get ahead of me, feel free to send a CL. Thanks. |
Not sure if this is related, but trying to cross-compile to darwin/arm64 with go1.16.2 produces a similar error (but darwin/amd64 works):
|
@yselkowitz yes, that looks similar to this. |
seeing similar issue attempting to build openshift-installer on Apple M1. I believe its related:
|
Note that @rcbaus' error is with forcing CGO_ENABLED=1 and linkmode external. With CGO_ENABLED=0 and default linkmode, the error on M1 Mac is the same that I got cross-compiling from Linux, as above. |
Change https://golang.org/cl/314451 mentions this issue: |
Change https://golang.org/cl/314452 mentions this issue: |
Change https://golang.org/cl/314456 mentions this issue: |
Compared to ARM32 or PPC64, ARM64 has larger range for direct jumps. But for very large programs it can still go over the limit. Add trampoline insertion for ARM64. Updates #40492. Change-Id: Id97301dbc35fb577ba3f8d5f3316a8424d4f53c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/314451 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
When internal linking with C objects, some C object relocations may be turned into a CALL via PLT. For very large programs, the PLT stub may be laid too far. PLT stubs are generated late in the linker, and laid out after the end of the text section. So if the text section is big, the PLT stubs are likely too far. To avoid this situation, add trampolines for PLT calls in the trampoline pass. Only do this when the program is known too large (i.e. the second pass of the two-pass algorithm). Updates #40492. Change-Id: I21f65d6cbc6bde84e3cf9c2ae05f5233df6cfa72 Reviewed-on: https://go-review.googlesource.com/c/go/+/314452 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Updates #40492, #30949. Change-Id: I6d7923ac83275c5ab08958f7a501f7975aea151a Reviewed-on: https://go-review.googlesource.com/c/go/+/314456 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
I submitted a few CLs related to this. Now it should work on Linux/ARM64 for both internal and external linking, with cgo enabled or disabled. On Darwin/ARM64 internal linking should work. Cgo can be enabled or disabled. External linking with cgo on still needs more work (the system linker is very picky). (Note: when building natively, cgo is by default enabled, and external linking is used by default. When cross compile, cgo is disabled by default and internal linking is by default used. It can be overridden by CGO_ENABELD=0/1 and -ldflags=-linkmode=internal/external.) This issue is originally about internal linking, which now should work on both Linux and Darwin. I'm going to call this fixed. If external linking on Darwin is a concern we can open a separate issue. Thanks. |
Change https://golang.org/cl/316050 mentions this issue: |
…king The Darwin linker does not like text sections that are larger than the jump limit (even if we already inserted trampolines). Split the text section to multiple smaller sections. Now external linking very large binaries works on Darwin/ARM64. Updates #40492. Change-Id: I584f1ec673170c5e4d2dc1e00c701964d6f14333 Reviewed-on: https://go-review.googlesource.com/c/go/+/316050 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
It now should work on Darwin/ARM64 with external linking as well. (Internal linking already works, as of last week.) |
What version of Go are you using (
go version
)?go version devel +85afa2eb19 Tue Jul 28 16:59:04 2020 +0000 linux/arm64
Also seen with go1.15rc1/1.14.6/1.13.14
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?linux/arm64
What did you do?
git clone https://github.com/openshift/installer
pushd installer
go build -mod=vendor -o bin/openshift-install ./cmd/openshift-install
What did you expect to see?
Build succeed.
What did you see instead?
For the record following is with the master branch go and gcc-10.1.1, gibc-2.31 and binutils-2.34 on (Fedora 32) host.
Using linkmode=external seems to work around the issue.
This reminds me of the similar issues with the external linker(on non-amd64 architectures) in the past #17028 . I'm bit surprised that this didn't got hit by any other "big binary" projects as kube, openshift,....
The text was updated successfully, but these errors were encountered: