NT_GNU_BUILD_ID有什么用?

What is NT_GNU_BUILD_ID used for?

我正在阅读 golang ld 的帮助指南,其中一个选项是

-B value
    Add a NT_GNU_BUILD_ID note when using ELF.  The value
    should start with 0x and be an even number of hex digits.

有谁知道为什么要使用那个标志?

搜索 NT_GNU_BUILD_ID 没有提供任何有见地的答案。

本文来自massive conversion from C to Go of cmd/new5l (Feb. 2015), translated from src/cmd/ld/pobj.c

该信息在 commit 7d507dc6e(2013 年 12 月,Go 1.3)中引入,为新的链接器结构做准备

NT_GNU_BUILD_IDmentioned here 作为唯一构建 ID 位串。
例如,您看到它在 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).

可以看到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.