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.
Nit: this probably wants to be a uint64_t rather than size_t max, right (since p_align could be uint64_t and therefore a larger type on 32-bit hosts than size_t)?