Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Aug 16, 2018 at 11:20 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/16/2018 09:16 PM, Mark Wielaard wrote:
>>
>> On Thu, Aug 16, 2018 at 04:21:05PM +0200, Florian Weimer wrote:
>>>
>>> On 08/16/2018 03:39 PM, H.J. Lu wrote:
>>>>
>>>> glibc only discards 4-byte aligned NT_GNU_PROPERTY_TYPE_0 note
>>>> since NT_GNU_PROPERTY_TYPE_0 note follows gABI.  If gold
>>>> generates 4 byte alignment, it is a gold bug.
>>>
>>>
>>> I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=23535
>>
>>
>> I don't think this is a bug in gold, but one in ld:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=22749
>>
>> In the GNU abi all ELF Notes are arrays of 32bit words
>> (and so 4-byte aligned). This is the same for most other
>> ELF systems. Making the ELF Notes fields 64bit words (and
>> so 8-byte aligned) in ELFCLASS64 would indeed be what gabi
>> literally says, but not what GNU systems, and others, follow.
>
>
> The binaries are already out there and will be around for a while, even if
> we reduce the alignment now.  So generic ELF parsers need to cope with these
> binaries anyway.
>
>> Having a mix of 4-byte words and 8-byte words ELF Notes
>> in the same ELF file seems unnecessarily confusing and
>> introduces extra segments and sections.
>
>
> There are no 8-byte word ELF notes on GNU systems, that's an HP-UX feature.
> The new 8-byte-aligned notes still have a four-byte header.
>
> 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.

Gold didn't follow the spec and should be fixed.

-- 
H.J.