cmd/link: go:buildinfo was not written in wasm

[Zxilly]

Go version

go version go1.24.3 windows/amd64

Output of go env in your module/workspace:

set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=0
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\zxilly\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\zxilly\AppData\Roaming\go\env
set GOEXE=
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-fPIC -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\zxilly\AppData\Local\Temp\go-build4032600516=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=T:\gotmp\go.mod
set GOMODCACHE=C:\Users\zxilly\go\pkg\mod
set GONOPROXY=1
set GONOSUMDB=
set GOOS=linux
set GOPATH=C:\Users\zxilly\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=on
set GOTELEMETRYDIR=C:\Users\zxilly\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.24.3
set GOWASM=
set GOWORK=
set PKG_CONFIG=pkg-config

What did you do?

Build a binary with GOOS=js GOARCH=wasm go build -o main.wasm main.go

What did you see happen?

go:buildinfo was not written into the binary.

What did you expect to see?

go:buildinfo was written like other arch.

[gopherbot]

Change https://go.dev/cl/673475 mentions this issue: cmd/link: attach buildinfo to wasm binary

[gabyhelp]

Related Issues

• wasm: no standard output on Windows #32774 (closed)
• unknown ptrSize for $GOARCH "wasm" #40543 (closed)
• cmd/link: don't resolve WebAssembly imports at link-time #29108
• cmd/distpack: wasm runtime js should be kept in the toolchain package #68024 (closed)
• path/filepath: WebAssembly uses *nix conventions on Windows #43768
• go build #35672 (closed)
• buildmode #57437 (closed)
• cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host #37472 (closed)
• go command #62170 (closed)
• go installing #71520 (closed)

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

[cherrymui]

Thanks for the issue. What is the user-visible effect of this? Thanks.

[Zxilly]

go version -m and buildinfo.Read cannot be applied to wasm files, at least with the current logic, which is to read a separate .go.buildinfo segment.

Of course, before we can do any of this, we'll probably also need a debug/wasm

[Zxilly]

In fact, we probably don't need a separate .go.buildinfo because that information is already embedded in the data segment as the symbol runtime.modinfo. But that's how all other platforms are implemented, and I'm inclined to be consistent for now.

ref: #73731

[cherrymui]

Okay, thanks. I agree that if we do this, we probably want to be consistent with other platforms, i.e. using a separate .go.buildinfo section, instead of reaching to specific symbols. (One can strip symbol names, but usually not section names.)

Yeah, we don't currently have a way to parse wasm files, so go version -m wouldn't work anyway. Is there a need to add buildinfo now? I'm okay with adding it now, but I'm a bit concerned that there is not a good way to test.

(Personally I'd like to have a wasm file parser, even if just internal, so go tool objdump etc. works. But it needs work.)

[Zxilly]

In fact, there is a much simpler way to do this, by checking src/cmd/go/internal/modload/build.go, where we can see that the buildinfo is wrapped around the corresponding magic number, which means that searching for the two magic numbers is usually enough to find the corresponding modinfo without having to rely on the symbol table.

However, this logic does not apply to wasm, because wasm's linker implements memory pack optimization, and consecutive modinfo string may be sliced and diced into different segments (which I think is unlikely to happen), in which case the modinfo string in the binary are not consecutive.

After retore the wasm memory, such logic can apply to wasm. There is a reference implementation in https://github.com/Zxilly/go-size-analyzer/blob/afd50eccac019aa51bca4dbc5eeca1cb7903e64e/internal/wrapper/wasm.go#L92-L123

[Zxilly]

It makes sense to provide an wasm parser in the standard library, because after checking the go ecosystem I found that there isn't a sufficiently robust implementation of a wasm parser, the best library I found came from binary decoder in wazero, but they chose to keep this library for the internal implementation.

[cherrymui]

Probably. Or it could be a third-party package. That would be a separate discussion (and proposal), though.

[cherrymui]

For this issue specifically, do you have a need for buildinfo now, before we have any parsing logic? Thanks.

[Zxilly]

I don't need it, as I said above, I implemented the runtime.modinfo parsing logic, and this issue was brought up mainly to align with other architectures.

[Zxilly]

I plan to add the magic-based parsing logic to buildinfo first, which should handle most wasm files, what do you think?

[Zxilly]

I reviewed the current implementation again, and it seems that parsing the build info on WebAssembly cannot be achieved before adding WASM parsing support. This is because the Go version information is added to the producers custom section, and without parsing the specific format of the WASM file, it's not possible to read it from the correct location.