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

go/build: default Context.ToolTags doesn't contain GOAMD64 setting from user config file #72791

Open
lersek opened this issue Mar 11, 2025 · 2 comments
Labels
BugReport Issues describing a possible bug in the Go implementation. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@lersek
Copy link

lersek commented Mar 11, 2025

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

$ go version
go version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700 linux/amd64

Does this issue reproduce with the latest release?

The reproducer is even more recent than the latest release (commit 73fea03 is the current HEAD of the master branch).

I originally encountered the symptom with my distro's go (go version go1.22.9 (Red Hat 1.22.9-2.el9_5) linux/amd64), but the problem reproduces with current upstream, too. The bug is being reported with go bug from upstream (at commit 73fea03).

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

go env Output
$ go env
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v2'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/lacos/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/lacos/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1652133164=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/lacos/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/lacos/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/lacos/src/upstream/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/lacos/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/lacos/src/upstream/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'
GOROOT/bin/go version: go version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700
uname -sr: Linux 5.14.0-503.26.1.el9_5.x86_64
/lib64/libc.so.6: GNU C Library (GNU libc) stable release version 2.34.

What did you do?

$ go env -w GOAMD64=v2
$ go env | grep -w GOAMD64
$ go run tooltags.go

where tooltags.go is

package main

import (
        "fmt"
        "go/build"
)

func main() {
        fmt.Println(build.Default.ToolTags)
}

What did you expect to see?

GOAMD64='v2'
[goexperiment.regabiwrappers goexperiment.regabiargs goexperiment.aliastypeparams goexperiment.swissmap goexperiment.spinbitmutex goexperiment.synchashtriemap amd64.v1 amd64.v2]

What did you see instead?

GOAMD64='v2'
[goexperiment.regabiwrappers goexperiment.regabiargs goexperiment.aliastypeparams goexperiment.swissmap goexperiment.spinbitmutex goexperiment.synchashtriemap amd64.v1]

The amd64.v2 tool tag is missing from build.Default.ToolTags.

Note that if I pass GOAMD64=v2 as an environment variable (i.e., not through my environment file /home/lacos/.config/go/env), then the result is as expected.

This issue breaks ABI level checks such as

@seankhliao seankhliao changed the title build.Default.ToolTags from go/build ignores GOAMD64=v2 from the user's environment *file* (not variable) go/build: default Context.ToolTags doesn't contain GOAMD64 setting from user config file Mar 11, 2025
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 11, 2025
@gabyhelp gabyhelp added the BugReport Issues describing a possible bug in the Go implementation. label Mar 11, 2025
@ianlancetaylor
Copy link
Member

That's an interesting case. The file set by go env -w is read by the go tool and the commands that it runs. It is not read by all Go programs. However, environment variables are read by all Go programs. So when you run an arbitrary Go program, such as your tooltags program, it will see the environment variables, but it won't see the variables set by go env -w.

I'm not sure that there is anything we can do here.

lersek added a commit to lersek/mkuimage that referenced this issue Mar 12, 2025
If the user builds an initrd for amd64, and their golang toolchain is
configured for an amd64 ABI version greater than 1, then issue a warning.

Binaries built for GOAMD64=v2+ may crash with an #UD exception on old
CPUs, or exit immediately (gracefully) with an error message like "This
program can only be run on AMD64 processors with v2 microarchitecture
support" [1]. Such a dysfunctional "init" (gobusybox) binary renders a
u-root initrd effectively unbootable. qemu-system-x86_64 with no
particular "-cpu" option is affected by this, for example.

GOAMD64 defaults to v1 [2], but it may be overridden in at least three
places (in increasing order of importance):

- the system-wide "go.env" file, such as "/usr/lib/golang/go.env",

- the user's "go.env" file, such as "$HOME/.config/go/env",

- the env var GOAMD64.

For example, RHEL9 and its derivative distros set GOAMD64 to v2 in
"/usr/lib/golang/go.env".

It seems like the canonical way for deducing GOAMD64 programmatically is
to invoke "go env GOAMD64" [3].

[1] golang/go@8c8baad927b2
[2] https://go.dev/wiki/MinimumRequirements#amd64
[3] golang/go#72791

Signed-off-by: Laszlo Ersek <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BugReport Issues describing a possible bug in the Go implementation. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants