Skip to content
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/link: put toolchain version in binary #13507

Closed
randall77 opened this issue Dec 6, 2015 · 7 comments

Comments

Projects
None yet
6 participants
@randall77
Copy link
Contributor

commented Dec 6, 2015

It would be nice to have a robust mechanism to tell what version of Go built a particular binary.

See go-nuts thread: https://groups.google.com/forum/#!topic/golang-nuts/XIDDj75ngMc

If the binary happens to call runtime.Version, then the version of Go is stored in runtime.buildVersion. If it doesn't call runtime.Version, runtime.buildVersion is dead-symbol eliminated.

We could teach cmd/link not to remove this symbol even if it is dead. Probably better is to just reference runtime.buildVersion from some always-used code (schedinit?). That way it will always be available in the binary, easily extracted with gdb.

@randall77 randall77 self-assigned this Dec 6, 2015

@randall77 randall77 added this to the Go1.7 milestone Dec 6, 2015

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2015

@randall77 i'd like to see this as well. A few years ago I suggested (cannot find the issue # anymore) that runtime.Version be printed in panic output. Doing this would solve the problem of keeping runtime.buildVersion alive, and also avoid having to much about with gdb to find the version string.

@minux

This comment has been minimized.

Copy link
Member

commented Dec 6, 2015

we already have https://golang.org/cl/117040043

It's now called runtime/internal/sys.BuildVersion
and it's accessible to gdb.

(gdb) p 'runtime/internal/sys.BuildVersion'
$1 = 0x482ea0 "devel +cd29463 Fri Dec 4 01:47:18 2015 +0000"

The variable will never be eliminated due to its
use in runtime/proc.go (introduced by CL 117040043)

Go 1.6 is the first version that the string is moved to
an internal package of runtime, for compatibility's sake,
I suggest that we move it back to runtime as runtime.buildVersion
than we have an robust method to access the version
starting from Go 1.4.

@randall77

This comment has been minimized.

Copy link
Contributor Author

commented Dec 6, 2015

Ok, excellent, didn't know about that one.

I'm not sure moving back to runtime.buildVersion would help. runtime.buildVersion isn't reliable in 1.4 because it can be eliminated at link time.

@randall77 randall77 closed this Dec 6, 2015

@minux

This comment has been minimized.

Copy link
Member

commented Dec 6, 2015

@gopherbot

This comment has been minimized.

Copy link

commented Dec 6, 2015

CL https://golang.org/cl/17459 mentions this issue.

@laboger

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2015

What about programs built with gccgo?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2015

@laboger For gccgo strings PROG | grep "gccgo " is reliable in that it will print the version, although of course other strings might match too.

minux added a commit that referenced this issue Dec 16, 2015

cmd/dist, runtime: make runtime version available as runtime.buildVer…
…sion

So that there is a uniformed way to retrieve Go version from a Go
binary, starting from Go 1.4 (see https://golang.org/cl/117040043)

Updates #13507.

Change-Id: Iaa2b14fca2d8c4d883d3824e2efc82b3e6fe2624
Reviewed-on: https://go-review.googlesource.com/17459
Reviewed-by: Keith Randall <khr@golang.org>

@golang golang locked and limited conversation to collaborators Dec 14, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.