Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

[Cary Coutant <ccoutant@gmail.com>]

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

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.

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). Why
should the loader have to go parsing everything in a generic PT_NOTE
segment anyway?

-cary

[1] https://groups.google.com/d/msg/x86-64-abi/-D05GQ3kWrA/stKtIPy8DQAJ