Re: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections

[Mark Mentovai <mark@chromium.org>]

I think that this recent change (commit 9a7bc47bf065) misses the
larger point. The alignment isn’t the only thing at issue here, the
very definition of the ELF note section is.

Quoting http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section:

> 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.

This is not followed by ELF on Linux (or, in fact, most other
systems), which define the note structure for 32-bit and 64-bit ELF
objects identically, as arrays of 4-byte words:

typedef uint32_t Elf32_Word;
typedef uint32_t Elf64_Word;
typedef struct {
  Elf32_Word n_namesz;
  Elf32_Word n_descsz;
  Elf32_Word n_type;
} Elf32_Nhdr;
typedef struct {
  Elf64_Word n_namesz;
  Elf64_Word n_descsz;
  Elf64_Word n_type;
} Elf64_Nhdr;

The requirement to use different note structures for 32-bit and 64-bit
objects is present in the 1998-04-29 gABI draft at earliest
(http://www.sco.com/developers/gabi/1998-04-29/ch5.pheader.html#note_section),
but is absent from Edition 4.1
(http://www.sco.com/developers/devspecs/gabi41.pdf#page=81), prior to
the standardization of the 64-bit format.

This structure’s alignment naturally follows its definition, and
specifically the sizes of the types involved.

As Linux deviates from the gABI in this not-insignificant way, the
Linux Extensions document ought to codify the distinction. The ELF
note structure definitions have been baked into too many places for
too much time to reasonably expect them to change.

Because Linux isn’t the only system to define the note structure in
this way even for 64-bit objects, it may be worth a mention in the
gABI as well, although I don’t know how to communicate this to its
maintainers.