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

lersek · 2025-03-11T15:13:54Z

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

go/src/cmd/compile/internal/amd64/versions_test.go

Line 41 in 73fea03

if tag == "amd64.v2" {

The text was updated successfully, but these errors were encountered:

gabyhelp · 2025-03-11T16:12:22Z

Related Issues

Related Code Changes

cmd/compile/internal/amd64: more robust detection of GOAMD64=v1

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

ianlancetaylor · 2025-03-11T16:40:15Z

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.

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 <laszlo.ersek@9elements.com>

lersek · 2025-03-12T17:45:26Z

@ianlancetaylor Thank you for the feedback!

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

I figured that whatever populates build.Default.ToolTags upon "program startup" (fuzzy term, I know), could just go ahead and read the env files as well.

At the same time, I've found a solution -- I can write

abi_level, err := exec.Command("go", "env", "GOAMD64").Output()

and verify the byte array abi_level (and handle errors properly, of course).

I'm OK if we close this ticket as "not planned" now. Thank you again for the help.

ianlancetaylor · 2025-03-12T20:43:02Z

I figured that whatever populates build.Default.ToolTags upon "program startup" (fuzzy term, I know), could just go ahead and read the env files as well.

It's not a big deal for the Go tools to read that file. It would be a big change for every Go program to read that file. And the documentation is that the file only affects the Go tools.

Closing. Thanks.

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 <laszlo.ersek@9elements.com>

lersek mentioned this issue Mar 11, 2025

README.md: advise GOAMD64=v1 for GOARCH=amd64 u-root/u-root#3316

Merged

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 added the NeedsInvestigation label Mar 11, 2025

gabyhelp added the BugReport label Mar 11, 2025

lersek mentioned this issue Mar 12, 2025

mkuimage: advise GOAMD64=v1 for GOARCH=amd64 u-root/mkuimage#40

Merged

ianlancetaylor closed this as not planned Mar 12, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

lersek commented Mar 11, 2025

gabyhelp commented Mar 11, 2025

ianlancetaylor commented Mar 11, 2025

lersek commented Mar 12, 2025 •

edited

Loading

ianlancetaylor commented Mar 12, 2025

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

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

Comments

lersek commented Mar 11, 2025

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

gabyhelp commented Mar 11, 2025

ianlancetaylor commented Mar 11, 2025

lersek commented Mar 12, 2025 • edited Loading

ianlancetaylor commented Mar 12, 2025

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

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

lersek commented Mar 12, 2025 •

edited

Loading