This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
On 08/22/2018 01:02 AM, Cary Coutant wrote:
But like you, I don't yet see the value of the 8-byte alignment. We could
decide that the current gold behavior is valid, fix glibc, and move on.
Right. gold seems to produce normal GNU abi ELF Notes, which should
be accepted as is.
NT_GNU_PROPERTY_TYPE_0 should stay to follow gABI.
That doesn't make any sense. gABI doesn't have a concept of 32bit word
ELF notes that are 8-byte aligned. That is just a bug in ld when it
generates the note. It also doesn't make sense to generate GNU ELF notes
with slightly different padding added depending on type in the same ELF
file. That just creates confusion, causes you to define different
alignments of notes resulting in extra PT_LOAD segments and results in
bugs like we are discussing now where ELF note parsers fail to parse
some (valid) notes. Lets just agree that the gold linker is correct and
produces consistent GNU abi ELF notes. And lets just fix ld to do the same.
I thought the outcome of the old discussion on the gABI/psABI mailing
lists was that there was no value in breaking compatibility by
introducing an 8-byte aligned note section.
The code for generating them is still in BFD ld and has been there for
several binutils releases. <cet.h> in GCC 8 generates 8-byte-aligned
notes, too.
glibc 2.28 assumes that no 4-byte-aligned PT_NOTE segments contain GNU
property notes and will search for such notes in 8-byte aligned segments
only. The glibc changes were formally reviewed and checked for
interoperability with BFD ld. I think we have (had) community consensus
for them.
We have built and hundreds (if not thousands) of binaries with
8-byte-aligned notes and shipped them (in Fedora), assuming that there
was upstream consensus about this x86-64 psABI extension.
As it is, the psABI definition of the gnu properties note is a
definitional disaster: like a proper note, it's got three 4-byte words
(namesz, descsz, and type), followed by the name field (which happens
to be 4 bytes long in this case), then a desc field. For this note,
the desc field contains a properties array, where each property has
two 4-byte values (pr_type and pr_datasz) and a data field padded to a
multiple of 8 bytes. But it describes the properties array as an array
of 8-byte words, even though it's really composed of the two 4-byte
words and an arbitrary-length buffer (which according to the spec, is
always 8 bytes). Why an 8-byte alignment, though? It doesn't provide
any conceivable benefit.
I think gold is doing the right thing by placing the output in a
4-byte aligned note section, and combining it with other note sections
in a 4-byte aligned PT_NOTE segment.
Based on what I've seen, this is a technically feasible option.
But we have existing binaries with 8-byte-aligned notes, and those won't
go away soon. There is a cost to having 8-byte-aligned notes (gold
fixes, elfutils fixes, plenty of other fixes), and to having
4-byte-aligned notes only (CET-compatible binaries will not be treated
as such because their 8-byte-aligned PT_NOTE section is invalid).
I don't know if there is anything else that is coming down the pipe
which would benefit from 8-byte-aligned notes. Nick has been working on
.gnu.build.attributes non-allocated note sections. They are nominally
4-byte-aligned, but contain 64-bit relocations, but so far, the linker
has not complained, so maybe this is okay.
As long as HJ is planning on breaking compatibility with his new
definition of the x86 properties [1], why not just throw it away and
do it right? Let's stop using NOTE sections for something they weren't
designed for, and instead use a special section type and segment type
(in keeping with existing models like Sun, HP, MIPS, and Arm).
This, too, would invalidate existing binaries.
Why should the loader have to go parsing everything in a generic PT_NOTE
segment anyway?
With 8-byte alignment, in practice, it is currently quite fast to
discover the new notes because the other notes have 4-byte alignment, so
the PT_NOTE segment with the property notes should be pleasantly short.
Again, maybe we shouldn't have built all those binaries, but we thought
the binutils community at least was in favor of the 8-byte-aligned
notes, This puts me in a difficult decision: The technical facts seem
to favor 4-byte-aligned notes (but again, there might be further
features that actually need 8-byte alignment). But the existing
binaries with 8-byte-aligned notes provide a strong business
justification for Red Hat to keep support for the 8-byte-aligned notes.
Thanks,
Florian
- References:
- PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold (was: Re: [PATCH] Document GNU_PROPERTY_X86_ISA_1_[USED|NEEDED])
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold (was: Re: [PATCH] Document GNU_PROPERTY_X86_ISA_1_[USED|NEEDED])
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold
- Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold