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.

Sign up for GitHub

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

Jump to bottom

cmd/link: put toolchain version in binary #13507

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

cmd/link: put toolchain version in binary #13507

randall77 opened this issue Dec 6, 2015 · 7 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@randall77
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Member

minux 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
Copy link
Contributor Author

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.

@minux
Copy link
Member

minux commented Dec 6, 2015 via email

@gopherbot
Copy link

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

@laboger
Copy link
Contributor

laboger commented Dec 7, 2015

What about programs built with gccgo?

@ianlancetaylor
Copy link
Contributor

@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
@minux
cmd/dist, runtime: make runtime version available as runtime.buildVer…
86f1944 
…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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
6 participants
@davecheney @minux @ianlancetaylor @randall77 @gopherbot @laboger