This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]