cmd/go: -buildmode=pie -ldflags -d produces executable which crashes on linux/amd64

[pinicarus]

Go version

1.26.5

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHEPROG=''
GODEBUG=''
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1018270336=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOVCS=''
GOVERSION='go1.26.5'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Trying to build a static PIE executable, using minimal main.go file:

package main

func main() {}

with this command: env CGO_ENABLED=0 go build -buildmode=pie -ldflags -d -o main main.go

What did you see happen?

The executable produced crashes with a segfault.

file ./main confirms that the executable is a ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped

readelf -r ./main gives There are no relocations in this file.

Running through gdb points the segfault here:

Program received signal SIGSEGV, Segmentation fault.
memeqbody () at go/src/internal/bytealg/equal_amd64.s:114
114		MOVQ	(SI), CX
#0  memeqbody () at go/src/internal/bytealg/equal_amd64.s:114
#1  0x00007ffff7f138a7 in runtime.vdsoFindVersion (info=0x7fffffffd8a8, ver=0x7ffff7fc5cd0 <runtime[vdsoLinuxVersion]>, ~r0=<optimized out>)
    at go/src/runtime/vdso_linux.go:197
#2  0x00007ffff7f13e1b in runtime.vdsoauxv (tag=<optimized out>, val=<optimized out>) at go/src/runtime/vdso_linux.go:284
#3  0x00007ffff7ee25ad in runtime.sysauxv (auxv=..., pairs=<optimized out>) at go/src/runtime/os_linux.go:322
#4  0x00007ffff7ee2305 in runtime.sysargs (argc=<optimized out>, argv=<optimized out>) at go/src/runtime/os_linux.go:251
#5  0x00007ffff7ef935c in runtime.args (c=4700277, v=0x9) at go/src/runtime/runtime1.go:70
#6  0x00007ffff7f1dc65 in runtime.args (c=1, v=0x7fffffffda18) at ./<autogenerated>:1
#7  0x00007ffff7f19cbd in runtime.rt0_go () at go/src/runtime/asm_amd64.s:371

What did you expect to see?

The executable should run fine.

Compiling with an external linker (gcc/ld on musl) produces an executable which runs correctly : go build -buildmode=pie -ldflags '-linkmode=external -extldflags=-static-pie' -o main main.go

[gabyhelp]

Related Issues

• go build: produces broken static pie files when build with `go build` instead of `go build -o outfile source.go` #62173 (closed)
• cmd/link: building static pie binaries using gcc -static-pie #41944 (closed)
• cmd/link: -buildmode=pie binaries fail to run on s390x #78171 (closed)
• cmd/go: default buildmode incompatible to external linker with PIE enabled by default #17847 (closed)
• cmd/link: produces invalid ELF sections (zeroth section has nonzero name) #76656 (closed)
• runtime: go compiler with PIE enabled by default race segv #31384 (closed)
• cmd/link: when building with `buildmode=pie` the DF_1_PIE flag should be added to the resulting elf #46747 (closed)
• cmd/go: buildmode=pie broken with -linkmode=internal and cgo #18968 (closed)
• cmd/link: failure of 'internal linking of -buildmode=pie' test on (some) Linuxes #17068 (closed)
• cmd/link: pie mode is not supported without cgo (linux/s390x) #77449 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[thepudds]

This seemed to reproduce on latest master.

FWIW, on the surface this seems like an old-ish problem. A quick-and-dirty bisect landed on b2696fd from 2020 for #35545, though that commit seems to be just enabling things rather than introducing a specific bug:

  first BAD:   b2696fde40 | 2020-02-25 15:13 | cmd/link: Revert -buildmode=pie to internal linking
  GOOD parent: 1858980645 | 2020-02-25 15:02 | cmd/go: fix typo in comment

Two other observations:

1. Dropping the -ldflags -d seemed to avoid the problem (at least at b2696fd).

2. The parent commit 1858980 did not seem to SEGV when running the binary, but building printed this warning (while reporting a 0 exit code):

# command-line-arguments
loadinternal: cannot find runtime/cgo

(Consider this a quick drive by comment. I did not look at this closely, so sorry if off base.)

[pinicarus]

Hello,

1. Dropping the -ldflags -d seemed to avoid the problem (at least at b2696fd).

FWIW, dropping this flag does not produce a static executable anymore.
It produces a dynamic executable but which works fine though.

Best regards

--
Pierre-Nicolas

[pinicarus]

Additionally, building a simple CLI using cobra (see below) gives a compile-time error:

$ go build -buildmode=pie -buildvcs=true -mod=readonly -trimpath -ldflags=-d -o main main.go
/usr/lib/go/pkg/tool/linux_amd64/link: /tmp/go-build/85/85895ea78003dcd59807f88c9a3b384a71d91b573bb328434d89ac762f1d32fb-d(_go_.o): cannot use dynamic imports with -d flag
/usr/lib/go/pkg/tool/linux_amd64/link: /tmp/go-build/83/83f21bb0c88bb879f105f56ca8440e0829f5beecbe281e14e12a0b17f0697f19-d(_go_.o): cannot use dynamic imports with -d flag
/usr/lib/go/pkg/tool/linux_amd64/link: /tmp/go-build/e9/e9c21735074acf6d9740977360157da66be59b10521c739ecb571e8c0710ef15-d(_go_.o): cannot use dynamic imports with -d flag
runtime.gcdata: missing Go type information for global symbol .dynsym: size 72
runtime/cgo(.text): relocation target stderr not defined
runtime/cgo(.text): relocation target fwrite not defined
runtime/cgo(.text): relocation target vfprintf not defined
runtime/cgo(.text): relocation target fputc not defined
runtime/cgo(.text): relocation target abort not defined
runtime/cgo(.text): relocation target pthread_mutex_lock not defined
runtime/cgo(.text): relocation target pthread_cond_wait not defined
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined
runtime/cgo(.text): relocation target pthread_key_create not defined
runtime/cgo(.text): relocation target stderr not defined
runtime/cgo(.text): relocation target fprintf not defined
runtime/cgo(.text): relocation target abort not defined
runtime/cgo(.text): relocation target pthread_setspecific not defined
runtime/cgo(.text): relocation target pthread_cond_broadcast not defined
runtime/cgo(.text): relocation target pthread_create not defined
runtime/cgo(.text): relocation target nanosleep not defined
runtime/cgo(.text): relocation target pthread_attr_init not defined
/usr/lib/go/pkg/tool/linux_amd64/link: too many errors

main.go:

package main

import (
	"fmt"

	"github.com/spf13/cobra"
)

func main() {
	var cmd cobra.Command
	err := cmd.Execute()
	fmt.Println(err)
}

[cherrymui]

PIE binaries are inherently dynamic. At least, it requires the dynamic linker to apply dynamic relocations. The -d flag is incompatible with that. We should simply error out. Maybe deprecate the -d flag entirely.

[pinicarus]

PIE binaries are inherently dynamic. At least, it requires the dynamic linker to apply dynamic relocations. The -d flag is incompatible with that. We should simply error out. Maybe deprecate the -d flag entirely.

PIE has its history rooted in dynamic executables, but it's also a thing for static executables for about a decade now.

If I get it right, the runtime has to ship a loader in the executable to resolve relocations at startup and the go runtime currently lacks one (and also seems not to produce the relocations at all).
A libc might provide such a loader, which is why building works with an external linker which has a -static-pie flag.

I can see this issue go one of two ways:

1. generate relocations and inject a loader in the produced static executable to resolve them
2. refuse to link with flag -d when buildmode is set to static-pie with an error stating that it's not supported (yet).

[cherrymui]

If the runtime needs to ship a loader, this is certainly not what the linker's -d flag is intended. Not something like -static-pie either. So this would be more of a feature request. And we should error out with -d and probably deprecate the flag.

[cagedmantis]

@golang/runtime