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
cmd/go: add 'go version <binary>' #31624
Comments
Change https://golang.org/cl/173343 mentions this issue: |
Change https://golang.org/cl/173342 mentions this issue: |
Change https://golang.org/cl/173341 mentions this issue: |
It is easier to ensure that the symbol is always present if we move it to package runtime. Avoids init-time work. Also moves it next to buildVersion, the other similar symbol. Setting up for "go version <binary>". For #31624. Change-Id: I943724469ce6992153e701257eb6f12da88c8e4e Reviewed-on: https://go-review.googlesource.com/c/go/+/173341 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is useful to be able to dig the Go version out of a binary, even a stripped binary. rsc.io/goversion does this for x86 binaries by disassembling the binary to find runtime/proc.go's startup-time reference to runtime.buildVersion's address. That approach is quite fragile: the implementation doesn't work for non-x86 and must be updated as the generated code changes. rsc.io/goversion finds the module version string by looking for random 16-byte framing around the actual string. This is less fragile but fairly kludgy and requires scanning the entire data segment. cmd/buildid finds the build ID by looking for an ELF note or else falling back to scanning the beginning of the text segment for a magic string. This has proved quite reliable and doesn't require scanning much of the binary. This CL makes it possible to find the Go and module versions using a scan more like the build ID scan: a symbol early in the writable data segment starts with a magic number and then has pointers to the two string variables. Setting up for "go version <binary>". For #31624. Change-Id: I78ea8c52fe1686b5cc5a829ca5f198104d10ebf0 Reviewed-on: https://go-review.googlesource.com/c/go/+/173342 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change https://golang.org/cl/175449 mentions this issue: |
I assume this was for debugging purposes. Updates #31624 Change-Id: Ie158fde0574c9bbbd9d1b684f51af5681974aff7 Reviewed-on: https://go-review.googlesource.com/c/go/+/175449 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
@rsc since this is now part of |
@mrueg note that the API to query Go packages and modules is For example, https://godoc.org/golang.org/x/tools/go/packages is a Go API that simply execs Following the same idea, I think you should be calling |
@mvdan Thanks for your response. I'm currently implementing a tool that will reconstruct a go.mod file from a given non-stripped go binary, so rsc/goversion works for that case and allows me to extract necessary details. I assume if I want to do and use golang's implementation my only option is extract the package into my repository? |
Many people find rsc.io/goversion useful.
It would be better as 'go version' instead of having
to download a separate tool.
The text was updated successfully, but these errors were encountered: