This comes from the massive conversion from C to Go of cmd/new5l
(Feb. 2015), translated from src/cmd/ld/pobj.c
That information was introduced in commit 7d507dc6e (Dec. 2013, for Go 1.3), a preparation for the new linker structure
NT_GNU_BUILD_ID
is mentioned here as a unique build ID bitstring.
You see it employed for instance in Fedora release build
To embed an ID into both the stripped object and its .debug
file, I've chosen to use an ELF note section.
strip
et al can keep the section intact in both files when its type is SHT_NOTE
.
The new section is canonically called .note.gnu.build-id
, but the name is not normative, and the section can be merged with other SHT_NOTE
sections.
The ELF note headers give name "GNU
" and type 3 (NT_GNU_BUILD_ID
) for a build ID note, of which there can be only one in a linked object (or an ET_REL
file of the .ko
style).
You can see it introduced in this patch in 2007:
This patch adds a new option to ld
for ELF targets, --build-id
.
It generates a synthetic ELF note section containing "unique build ID
" bits
chosen by ld
.
This is done as an ld
option to be efficient and foolproof to enable for
every compilation (vs some script adding a generated object into the link).
It's done the way it is so it can use no more and no less than the exact
final ELF bits of the output to contribute to selecting a unique ID.
This is the best way to ensure that deterministic styles of ID generation
(i.e. cryptographic hash) will always yield identical results for repeated
builds reproduced precisely.