This is the mail archive of the
mailing list for the glibc project.
Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: x86-64-abi <x86-64-abi at googlegroups dot com>, Binutils <binutils at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Mark Wielaard <mark at klomp dot org>, Michael Matz <matz at suse dot de>, Nick Clifton <nickc at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, szabolcs dot nagy at arm dot com
- Date: Wed, 26 Sep 2018 10:39:30 -0700
- Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- References: <CAMe9rOrrayKnc_cPm4SmnDnUGLbBUmOYMBTMOM8KLAHVmb=rUQ@mail.gmail.com> <email@example.com> <firstname.lastname@example.org>
> 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
> 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
> # 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,
> (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.