Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This is a proposal to add extensive build meta information to Go binaries for various use cases like:
Currently it is hard to retrieve meta information from Go binaries - either information is missing completely or extraction requires extensive parsing of the binary file. The following table lists existing metadata entities and the mechanism required to extract the information.
This proposal is to provision extended build time meta information to Go binaries. Reading the information from binaries shall be trivial.
go.buildid is provisioned in PT_NOTE segment for ELF based systems (see note sections (2-4)). In case of executable file formats which do not define appropriate mechanisms for enclosing meta information (like e.g. Windows PE),
Thus, a portable mechanism for meta information provisioning is already in place and can be re-used for build meta information. The proposed name for build meta information is
This could get arbitrarily complex. We already have the first two rows in the table, accessible using
Generalizing to JSON will just make the binaries bigger and create more work for existing parsers, for very little benefit.
Generalizing to arbitrary metadata similarly adds complexity with not much benefit.
I think we should probably stop where we have stopped.
@rsc - as you outlined, some of the data is already available with
Tools (not necessarily implemented in Go) which operate on application meta information have to deal with all sorts of technologies. Performance monitoring tools and vulnerability scanners supervise production systems.
This reasoning led us to propose JSON formatted build meta information. The very minor increase in binary size is in our view outweight by its extendability, standardization, and availability of proven parsers. But JSON format is in no terms a mandatory requirement. If size is a roadblock, it can be substituted with another, more lightweight format.
Thus, we think the proposal adds significant benefits to Go, by bringing it en par with other technologies.
When you say "en par with other technologies" which technologies are you thinking of? If other languages are providing this kind of information we should consider doing what they do rather than inventing something new.
Note that for specific purposes the linker's
@ianlancetaylor [disclaimer - I am co-author of the proposal]
To my knowledge - no standardized deployment mechanism or defined set of meta information that Go could directly re-use exists. We tried to compile a set of properties, that seemed reasonable for
In shortcoming of a better mechanism, we did propose to follow the
Different technologies use very divergent schemes and formats. Many technologies simply leverage from not being bound to a specific file format (like ELF or PE). Others, from being backed
Node.js has package.json file, which defines a rich set of information (name, version, license,
.Net manifest files contain a quite rich set of meta information (referenced assemblies, version,
Java has a subset of the proposed information in its manifest file.