The asker is parsing PT_NOTE segments and SHT_NOTE sections in real ELF binaries and finds that the format documented in elf(5) — a 12-byte header (namesz, descsz, type) followed by name and desc, each padded to a 4-byte boundary — doesn't match everything they see in the wild. They're asking why there appears to be a second, undocumented layout.

Why this is a real trap, not a mistake. The confusion isn't imaginary: the ELF gABI, glibc, binutils, and the Linux kernel have historically disagreed on the alignment rule for 64-bit notes. Three positions coexist in the ecosystem:

• gABI (formal reading): for ELFCLASS64, the name and desc fields should be padded to 8-byte boundaries — a "64-bit note" (sometimes called Elf64_Nhdr).
• Reality on Linux/GNU: essentially all .note.* sections use 4-byte alignment even on 64-bit ELF. This is what elf(5) documents, and it's what binutils emits.
• Core dumps and a few vendor notes: may follow the 8-byte rule, or embed sub-structures (like NT_FILE or NT_GNU_PROPERTY_TYPE_0) whose internal layout depends on ELF class and looks like "a second format" if you're only inspecting the outer bytes.

Approach. Trust the section/segment's sh_addralign/p_align field — that's the alignment the producer intended, and modern binutils sets it correctly (usually 4, occasionally 8). Then:

1. Read the 12-byte header at the current offset.
2. Advance namesz bytes for the name, then align to sh_addralign.
3. Advance descsz bytes for the desc, then align again.
4. Repeat until the segment/section ends.

For the well-known GNU notes (NT_GNU_BUILD_ID, NT_GNU_PROPERTY_TYPE_0, NT_GNU_ABI_TAG), and for core-dump notes (NT_PRSTATUS, NT_FILE, NT_PRPSINFO), the desc payload has its own structured layout — that's likely the "second format" the asker is seeing. It isn't a second note format; it's a typed payload inside the note.

Gotchas. The Linux kernel's fs/binfmt_elf.c historically padded to 4 bytes for core notes regardless of ELF class, so a strictly gABI-conformant parser will misread real Linux core files. Cross-check against readelf -n, which handles both conventions. And watch for NT_GNU_PROPERTY_TYPE_0: its outer alignment matches the section's, but its inner property array is aligned to sizeof(void*), which really does differ between ELF32 and ELF64.