proposal: cmd/go: go version to support non-executable Go binaries

[qmuntal]

The go version command only supports executable files, restriction that is stated in its documentation:

Go version reports the Go version used to build each of the named executable files.

This restriction is implemented by checking for a .exe file extension on Windows and by checking if the file has 0111 permissions.

go/src/cmd/go/internal/version/version.go

Lines 107 to 112 in 4d66d77

	func isExe(file string, info fs.FileInfo) bool {
	if runtime.GOOS == "windows" {
	return strings.HasSuffix(strings.ToLower(file), ".exe")
	}
	return info.Mode().IsRegular() && info.Mode()&0111 != 0
	}

I propose that go version should also support non-executable binaries, such as binaries compiled using buildmode=c-shared and buildmode=c-archive, as these binaries can also contain useful version data.

See #45234 for a detailed use-case.

@rsc

[rsc]

It sounds like maybe the version info is there, and we don't look for it?

/cc @jayconrod @bcmills

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[bcmills]

If there is a straightforward fix to the go version subcommand, I think we should just fix it (with an accompanying regression test). I'm not sure that a formal proposal is really needed.

If the fix is not straightforward, then I think this will ultimately fall into a much-needed “buildmode cleanup” bucket, which is probably long overdue but also difficult to prioritize.

[jayconrod]

Build info is stamped into files built in c-archive and c-shared mode, but go version doesn't attempt to read it.

It might be very simple to extend go version -m to work with files built in c-shared mode. The only thing I'm not sure about is whether we need to apply relocations when reading information out of the binary. I don't think so since we're not actually loading the binary into memory.

c-archive is a little harder: go version -m would need to understand the archive format enough to find the executable within it.

[ianlancetaylor]

Note that we have archive reading code in cmd/link/internal/ld/ar.go.

[josharian]

If we can tolerate extremely rare false positives, it may also be cheaper and easier not to parse the file at all. See e.g. tailscale/tailscale@a4e19f2.

[rsc]

We already don't really parse the file, except to find the start of the data segment. Sometimes the data segment is very far into the binary, so we use the parsing to skip to at least the right approximate place. I suppose we could just read the entire file but that's going to be slower.

[rsc]

It sounds like this is probably pretty easy and that we should just do it.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[gopherbot]

Change https://golang.org/cl/357569 mentions this issue: debug/buildinfo: add regression tests for different buildmodes

[qmuntal]

I've added some more debug/buildinfo tests in CL 357569 to ensure it can retrieve buildinfo from exe, pie and c-shared buildmodes.

I haven't added a test for c-archive because it fails on my computer (windows/amd64) with the error unrecognized file format.