cmd/link: broken with binutils that generates STT_COMMON symbols

[moben]

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

go version go1.7.1 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/x86_64-pc-linux-gnu/lib/go"
GOTOOLDIR="/usr/x86_64-pc-linux-gnu/lib/go/pkg/tool/linux_amd64"
CC="x86_64-pc-linux-gnu-cc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build450521412=/tmp/go-build -gno-record-gcc-switches"
CXX="x86_64-pc-linux-gnu-c++"
CGO_ENABLED="1"

What did you do?

We built binutils with --enable-elf-stt-common. This makes the gnu assembler/objcopy and ld default to generating common symbols with the STT_COMMON type.

What did you see?

This makes go break at runtime with:

..../go/pkg/linux_amd64/runtime/cgo.a(_all.o): malformed elf file: runtime/cgo(.text)#40: reloc of invalid sym #65 x_cgo_threadentry shndx=65522 type=5

If binutils was not configured this way, this should be reproducible by passing --elf-stt-common=yes and -z common to the assembler and linker respectively when builing go. I wasn't able to do this but that's probably due to my unfamiliarity with go's build system.

How to fix this?

go could pass --elf-stt-common=no and -z nocommon when building itself or anything else. However I don't think that's workable, as then it would not be able to link to objects that were created with those flags set.

[bradfitz]

Can you try Go master? (what will be Go 1.8)

Or wait a few days for the first beta if you don't want to run src/make.bash.

[gopherbot]

CL https://golang.org/cl/33653 mentions this issue.

[moben]

I can confirm that it happens on master and that https://golang.org/cl/33653 fixes it.