Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

[Cary Coutant <ccoutant at gmail dot com>]

> At the GNU Tools Cauldron in Manchester, we had an ad-hoc side meeting
> to work out a consensus among many of those involved so far.
>
> I'm including the minutes below.  It is my hope that this can serve as a
> guide for obtaining community consensus.
>
> Cary, after reviewing the minutes, would you be willing to join the
> emerging consensus, and re-review H.J.'s patch to align gold's behavior
> with BFD ld?

Yes, I will yield to the consensus, and I'll change gold's treatment
of the new note section.

But please allow me to express my disappointment and a few minor
quibbles for the record....

> Putting the markup in a new, separate program header segment (PT_*)
> has more risk across the ecosystem than PT_NOTE.  We know that PT_NOTE
> works because different new notes have been added to the PT_NOTE
> segment over time.

It's discouraging that the community is so reluctant to make use of
the established and well-proven extension mechanism that was designed
into ELF. An extension mechanism that people are afraid to use is not
an extension mechanism. I think it's a bit hyperbolic to imply that we
*don't* know that a new segment type for this purpose will work, since
that very mechanism has already been put to use on at least 3
platforms.

> gABI does not completely and unambiguously describe the layout of note
> segments and sections and the format of the note header, although the
> historic interpretation has been that the note header has three 32-bit
> words, independently of the ELF class, particularly on GNU/Linux.
> (But HP-UX uses 8-byte words in the note header in the 64-bit case.)

I think it's more fair to say that the gABI does in fact completely
and unambiguously describe the layout of 64-bit note sections, but
that Sun and Gnu accidentally misread or ignored the spec in their
implementations, establishing a precedent that led to confusion and
compatibility issues. The choice to use 8-byte alignment for this note
-- ignoring public objections to the design -- added even more
confusion.

> # Some available options
>
> (1) Only 4-byte-aligned notes are valid.  Existing binaries with 8-byte
> alignment become invalid.
>
> (2) The current 8+4 alignment mix (8-byte alignment for GNU Property
> notes on ELFCLASS64, 4-byte alignment for older note types such as ABI
> tag and build ID) as implemented by BFD ld, GCC, and glibc.
>
> (3) Change GCC and linkers to generate 4-byte-aligned notes
> (producers), but keep backwards compatibility with existing
> 8-byte-aligned notes in binaries (in consumers).
>
> (4) A new PT_* segment for property notes.
>
> # Consensus position of those present
>
> (4) Does not have working code today, so it was not considered
> further. (It is also considered larger risk, as discussed above.)
>
> A simplification over the status quo is not achievable with (3)
> because consumers still need to be updated.  This means the choice is
> between (1) and (2).

If the solution must meet the criterion that consumers don't need to
be updated, then (1) is not a choice, as you noted below. If that was
indeed an immutable criterion, this meeting wasn't really necessary,
was it?

> (1) makes existing binaries invalid, and there was general agreement
> that this is a bad idea.  It also fails to support notes with relocation
> on ELFCLASS64 strict-alignment targets.
>
> This leaves us with (2).  There was agreement that link editor
> behavior for this approach is currently underspecified.  Some
> ABI-level document should indicate what linkers should do (for
> example, produce separate PT_NOTE segments for different alignments,
> report link failures for note sections of different alignment and the
> same name in relocatable links).
>
> In order to obtain consensus among those present, we agreed that option
> (2) (that is, 8+4 alignment mix as implemented in BFD ld, GCC, and glibc
> today) should only be adopted with 8-byte-alignment for the GNU property
> notes, and not automatically for all future notes.  No precedent for
> future notes should be established by this decision.

I'm happy you've decided to restrict this solution to just the one
note. I'd prefer, however, that we do establish a precedent that this
should be the only exception, and that *all* future notes must follow
the a priori convention of using 4-byte aligned notes (on those
platforms that did not implement according to the gABI spec).

> Florian agreed to try to document the expected link editor behavior
> regarding notes and note merging.

Some requirements I'd like to see:

(1) An NT_GNU_PROPERTY_TYPE_0 note section must be named
".note.gnu.property" with type SHT_NOTE.

(2) A ".note.gnu.property" section must contain one and only one note,
whose type must be NT_GNU_PROPERTY_TYPE_0.

(3) A ".note.gnu.property" section must have sh_align of 8, and its
length must be a multiple of 8.

(4) A linker is expected to combine ".note.gnu.property" sections in a
manner described by the ABI documentation, and place the combined
result, as a single note, in a unique SHT_NOTE section named
".note.gnu.property", and in a unique PT_NOTE segment.

-cary