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

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.)}

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

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

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

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.)

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

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.

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

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

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.