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
22 lines
671 B
Plaintext
22 lines
671 B
Plaintext
# RUN: yaml2obj --docnum=1 %s -o %t1.so
|
|
# RUN: llvm-readelf --notes %t1.so 2>&1 | FileCheck %s -DFILE=%t1.so
|
|
# RUN: llvm-readobj --notes %t1.so 2>&1 | FileCheck %s -DFILE=%t1.so
|
|
|
|
# CHECK: warning: '[[FILE]]': unable to read notes from the SHT_NOTE section with index 1: alignment (6) is not 4 or 8
|
|
|
|
--- !ELF
|
|
FileHeader:
|
|
Class: ELFCLASS64
|
|
Data: ELFDATA2LSB
|
|
Type: ET_EXEC
|
|
Sections:
|
|
- Name: .note.invalid
|
|
Type: SHT_NOTE
|
|
AddressAlign: 0x0000000000000006
|
|
Content: 0400000004000000cdab0000474E550061626364
|
|
ProgramHeaders:
|
|
- Type: PT_NOTE
|
|
FileSize: 0x20
|
|
FirstSec: .note.invalid
|
|
LastSec: .note.invalid
|