[Object] Fix handling of Elf_Nhdr with sh_addralign=8
authorFangrui Song <i@maskray.me>
Wed, 10 May 2023 16:36:58 +0000 (09:36 -0700)
committerFangrui Song <i@maskray.me>
Wed, 10 May 2023 16:36:58 +0000 (09:36 -0700)
commit689715f335aeffc0e9583ac1b2a5629b6dd47876
tree92ecb250acaed017ba787e819ae1383a1f6ceb63
parentae63d5be37fe2f2a73734e812c596d1a30b4016f
[Object] Fix handling of Elf_Nhdr with sh_addralign=8

The generic ABI says:

> Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz.

Our parsing code currently aligns n_namesz. Fix the bug by aligning the start
offset of the descriptor instead. This issue has been benign because the primary
uses of sh_addralign=8 notes are `.note.gnu.property`, where
`sizeof(Elf_Nhdr) + sizeof("GNU") = 16` (already aligned by 8).

In practice, many 64-bit systems incorrectly use sh_addralign=4 notes.
We can use sh_addralign (= p_align) to decide the descriptor padding.
Treat an alignment of 0 and 1 as 4. This approach matches modern GNU readelf
(since 2018).

We have a few tests incorrectly using sh_addralign=0. We may make our behavior
stricter after fixing these tests.

Linux kernel dumped core files use `p_align=0` notes, so we need to support the
case for compatibility.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D150022
lld/ELF/InputFiles.cpp
llvm/include/llvm/Object/ELF.h
llvm/include/llvm/Object/ELFTypes.h
llvm/lib/Object/BuildID.cpp
llvm/test/tools/llvm-readobj/ELF/AArch64/aarch64-note-gnu-property.s
llvm/test/tools/llvm-readobj/ELF/note-alignment-invalid.test [new file with mode: 0644]
llvm/test/tools/llvm-readobj/ELF/note-gnu-property2.s
llvm/test/tools/llvm-readobj/ELF/note-unknown.s
llvm/tools/llvm-readobj/ELFDumper.cpp
llvm/tools/obj2yaml/elf2yaml.cpp
llvm/unittests/Object/ELFTypesTest.cpp