Originally reported at https://lore.kernel.org/linux-perf-users/CAP-5=fUC88TVwnjTuTgU+s=LqqP0xOhNTG5hU27cSbaZRH7Jpg@mail.gmail.com/ $ cat a.s .text .global main .global foo main: foo: ret $ cat b.s .text .global main .global bar main: bar: ret $ gcc -Wl,--build-id a.s -o a.out $ gcc -Wl,--build-id b.s -o b.out $ readelf -n a.out ... Build ID: 9dd0371b953db5d72929af5d98552e4ee1043616 ... $ readelf -n b.out ... Build ID: 9dd0371b953db5d72929af5d98552e4ee1043616 ... write_build_id calls bfd/elfcode.h:elf_checksum_contents, which hashes the ELF header, program headers, section headers and contents. However, .symstr .strtab .shstrtab are special ` sec = bfd_section_from_elf_index (abfd, count);` returns NULL for the three sections, causing their contents to be unused in the final build ID.
There's `special_sections` but only xcoff has that. But there is elf_backend_special_sections, though that doesn't have these either.
Ah, they're in special_sections_s, and then in special_sections in elf.c (sorry, I was wrong about XCOFF-only).
The answer from Chatgpt: All SHF_ALLOC sections These are sections that will be loaded into memory at runtime, such as: .text .rodata .data .got .plt .init .fini .ctors / .dtors Any custom sections marked SHF_ALLOC Sections not used for build-id These are ignored: .note.gnu.build-id itself Debugging sections: .debug_*, .gdb_index, .debug_line, etc. .comment .symtab, .strtab, .dynsym .rela.*, .rel.* Any non-ALLOC sections Section names reserved for toolchain metadata And Chatgpt also says GNU document doesn't confirm that.