Description
[Note: splitting this issue off from #58425, since although it was reported there and is related, this is actually a separate problem in the Go linker]
What version of Go are you using (go version)?
$ go version go version go1.20.2 linux/amd64
Does this issue reproduce with the latest release?
Yes. Also an issue for 1.19.
What operating system and processor architecture are you using (go env)?
Problem is with 32-bit arm.
What did you do?
Download and build grafana agent for ARM (here I'm doing this from a linux/amd64 machine with a cross-compiler installed):
$ git clone https://github.com/grafana/agent.git
$ cd agent
$ git checkout 2eb10ae840faf565f8eb063a79a8f1d826fb9483
$ cat t.sh
#!/bin/sh
set -x
set -e
rm -f grafana-agent.exe
rm -rf tmpdir
mkdir tmpdir
GOOS=linux \
CC=/usr/bin/arm-linux-gnueabihf-gcc \
GOARCH=arm \
GOARM=7 \
CGO_ENABLED=1 \
CGO_CFLAGS=" -mlong-calls" \
go build -ldflags="-v -tmpdir=tmpdir" -tags "netgo " \
-x -o /tmp/grafana-agent.exe ./cmd/grafana-agent
$
What did you expect to see?
Clean build.
What did you see instead?
tmpdir/go.o: in function `k8s.io/api/storage/v1.(*VolumeError).Unmarshal':
/ssd2/go1/pkg/mod/k8s.io/[email protected]/storage/v1/generated.pb.go:5158:(.text+0x207bc74): relocation truncated to fit: R_ARM_CALL against `runtime.morestack_noctxt'
I looked at the relocation in question, and from my calculations the calculated displacement is exactly at the lower limit of the relocation in question (e.g. the minimum value represented by a signed 24-bit quantity, or -0x800000). Source of the relocation (this is from objdump -dr):
207bc70: mov r3, lr
207bc74: bl 0x207bc74 <k8s.io/api/storage/v1.(*VolumeError).Unmarshal+0x6cc> @ imm = #-8
0207bc74: R_ARM_CALL runtime.morestack_noctxt
and target of the relocation is at 0x0007bc74 with offset of 1740, so this computation here yields exactly -0x800000.
Bottom line is that this is a disagreement between the Go linker's calculation of what will reach and the external linker's calculation.
For this line here in the Go linker
if t > 0x7fffff || t < -0x800000 || ...
if I change t < -0x800000 to t <= -0x800000 the program links ok.
So although the symptom is the same as , this looks like a slightly different bug.