Different files with the same build ID should contain the same executable
content.
See the
-.IR \-\-build\-id
+.BR \-\-build\-id
option to the GNU linker (\fBld\fR (1)) for more details.
This section is of type
.BR SHT_NOTE .
.\" FreeBSD: https://svnweb.freebsd.org/base/head/sys/sys/elf_common.h?revision=303677&view=markup#l33
.\" NetBSD: https://www.netbsd.org/docs/kernel/elf-notes.html
.\" OpenBSD: https://github.com/openbsd/src/blob/master/sys/sys/exec_elf.h#L533
+.\"
.SS Notes (Nhdr)
ELF notes allow for appending arbitrary information for the system to use.
-They are largely used by core files (\fIe_type\fR of \fIET_CORE\fR),
+They are largely used by core files
+.RI ( e_type
+of
+.BR ET_CORE ),
but many projects define their own set of extensions.
-For example, the GNU project passes info from the linker to the C library.
+For example,
+the GNU project passes information from the linker to the C library.
-Note sections contain a series of notes (see the structs below).
+Note sections contain a series of notes (see the
+.I struct
+definitions below).
Each note is followed by the name field (whose length is defined in
\fIn_namesz\fR) and then by the descriptor field (whose length is defined in
\fIn_descsz\fR) and whose starting address has a 4 byte alignment.
Neither field is defined in the note struct due to their arbitrary lengths.
An example for parsing out two consecutive notes should clarify their layout
-in memory.
+in memory:
.in +4n
.nf
void *memory, *name, *desc;
Elf64_Nhdr *note, *next_note;
-/* The buffer is pointing to the start of the section/segment. */
+/* The buffer is pointing to the start of the section/segment */
note = memory;
-/* If the name is defined, it follows the note. */
+
+/* If the name is defined, it follows the note */
name = note->n_namesz == 0 ? NULL : memory + sizeof(*note);
-/* If the descriptor is defined, it follows the name (with alignment). */
+
+/* If the descriptor is defined, it follows the name
+ (with alignment) */
+
desc = note->n_descsz == 0 ? NULL :
memory + sizeof(*note) + ALIGN_UP(note->n_namesz, 4);
-/* The next note follows both (with alignment). */
+
+/* The next note follows both (with alignment) */
next_note = memory + sizeof(*note) +
- ALIGN_UP(note->n_namesz, 4) + ALIGN_UP(note->n_descsz, 4);
+ ALIGN_UP(note->n_namesz, 4) +
+ ALIGN_UP(note->n_descsz, 4);
.fi
.in
.B n_name = GNU
Extensions used by the GNU tool chain.
.RS
-.TP 21
-.PD 0
+.TP
.B NT_GNU_ABI_TAG
OS ABI information.
The desc field will be 4 words:
- word 0: OS descriptor (\fBELF_NOTE_OS_LINUX\fR, \fBELF_NOTE_OS_GNU\fR, etc...)
- word 1: major version of the ABI
- word 2: minor version of the ABI
- word 3: subminor version of the ABI
+
+.PD 0
+.RS
+.IP \(bu 2
+word 0: OS descriptor
+(\fBELF_NOTE_OS_LINUX\fR, \fBELF_NOTE_OS_GNU\fR, and so on
+.IP \(bu
+word 1: major version of the ABI
+.IP \(bu
+word 2: minor version of the ABI
+.IP \(bu
+word 3: subminor version of the ABI
+.RE
+.PD
.TP
.B NT_GNU_HWCAP
Synthetic hwcap information.
The desc field begins with two words:
- word 0: number of entries
- word 1: bitmask of enabled entries
-.br
+
+.PD 0
+.RS
+.IP \(bu 2
+word 0: number of entries
+.IP \(bu
+word 1: bit mask of enabled entries
+.RE
+.PD
+.IP
Then follow variable-length entries, one byte followed by a null-terminated
hwcap name string.
-The byte gives the bit number to test if enabled, (1U << bit) & bitmask.
+The byte gives the bit number to test if enabled, (1U << bit) & bit mask.
.TP
.B NT_GNU_BUILD_ID
-Unique build ID as generated by GNU ld's \fI--build-id\fR.
+Unique build ID as generated by the GNU
+.BR ld (1)
+.BR \-\-build\-id
+option.
The desc consists of any nonzero number of bytes.
.TP
.B NT_GNU_GOLD_VERSION
The desc contains the GNU Gold linker version used.
-.PD
.RE
-
.TP
.B Unknown system
The fallback set of note types when the namespace is unknown.
-Usually the name field will be omitted (i.e.
+Usually the name field will be omitted (i.e.,
.B n_namesz
will be set to 0).
.RS