Clear up confusion on elf32 vs elf64 notes which in fact are the same

[wanders]

The definitions of note sections (and segments) for Elf32 and Elf64 is a bit of a mess. There is a specification saying Elf64 should use 8-byte fields. But noone does that.

(The alignment may however differ, but that is a different thing)

N.B this changes the type of the publically visible NoteAny.n_type

Sources

linux

LSB elf.h says Elf32_Nhdr and Elf64_Nhdr are identical:
https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libc-ddefs.html

But also in Executable And Linking Format (ELF) refers to "System V ABI Update" which specifies it as using 8-byte fields for namesz, descsz and type.

freebsd

Elf32_Nhdr
https://github.com/freebsd/freebsd-src/blob/b9a60d36ba043f313ab98b8dd058d49559254791/sys/sys/elf64.h#L172
and Elf64_Nhdr
https://github.com/freebsd/freebsd-src/blob/b9a60d36ba043f313ab98b8dd058d49559254791/sys/sys/elf32.h#L158
typedeffed to same thing: https://github.com/freebsd/freebsd-src/blob/b9a60d36ba043f313ab98b8dd058d49559254791/sys/sys/elf_common.h#L48

Solaris

https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html clearly states that it is 4-byte words for both 32-bit and 64-bit systems.

Illumos (opensolaris)

Elf32_Nhdr and Elf64_Nhdr has same definition: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/elf.h#L854

Also, elfnote writing has this comment: https://code.illumos.org/plugins/gitiles/illumos-gate/+/refs/heads/master/usr/src/uts/common/exec/elf/elf.c#1605

	/*
	 * The System V ABI states that n_namesz must be the length of the
	 * string that follows the Nhdr structure including the terminating
	 * null. The ABI also specifies that sufficient padding should be
	 * included so that the description that follows the name string
	 * begins on a 4- or 8-byte boundary for 32- and 64-bit binaries
	 * respectively. However, since this change was not made correctly
	 * at the time of the 64-bit port, both 32- and 64-bit binaries
	 * descriptions are only guaranteed to begin on a 4-byte boundary.
	 */

GHC

The best source explaining this mess I found in a comment of GHC's elf module: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/SysTools/Elf.hs#L81

LLVM

https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Object/ELFTypes.h#L596

everything as Elf_Word (=u32)

Commit message of this commit

At least linux, freebsd and llvm headers define Elf32_Nhdr:
  Elf32_Word n_namesz;
  Elf32_Word n_descsz;
  Elf32_Word n_type;

and Elf64_Nhdr as:
  Elf64_Word n_namesz;
  Elf64_Word n_descsz;
  Elf64_Word n_type;

Both Elf32_Word and Elf64_Word correspond to u32 (Half, Word, Xword types are the same for Elf32 and Elf64, while types such as Addr and Off differ).

Note (no pun intended) that this contradicts
  System V Application Binary Interface - DRAFT - 24 April 2001
which says:

> Note Section
> ...
> The note information in sections and program header elements holds a
> variable amount of entries. In 64-bit objects (files with
> e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of
> 8-byte words in the format of the target processor. In 32-bit objects
> (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry is an
> array of 4-byte words in the format of the target processor. Labels
> appear below to help explain note information organization, but they
> are not part of the specification.

But according to
  SysTools.Elf from GHC
  https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/SysTools/Elf.hs#L81
"nobody" does that:

> In practice, for almost all platforms namesz, descz and type fields
> are 4-byte words for both 32-bit and 64-bit objects (see elf.h and
> readelf source code).
>
> The only exception in readelf source code is for IA_64 machines with
> OpenVMS OS