[PATCH] D59120: [ELF] Sort notes by alignment in decreasing order

[Rui Ueyama via llvm-commits]

The other way to address this issue in theory would be to define how to
align each .note section in a PT_NOTE segment. It is actually pretty easy
to identify padding between .note sections if padding is just
zero-initialized bytes, as each .note section always starts with a 4-byte
"length" field which is always a non-zero value. Thus, if we just align
each .note section to its alignment requirement and leave padding as-is,
the result would be in theory readable.

Of course, the problem is that being readable in theory is different from
being readable by the existing programs. So I don't think it is a practical
solution (so I don't think we can do that in practice), but if we want to
fix it at the ABI level, that's one way of doing it.

On Mon, Mar 11, 2019 at 11:51 AM Jake Ehrlich <jakehehrlich at google.com>
wrote:

> Rui is correct and I think pcc's proposal is the only way IMO. Consider
> two note sections with page alignment (or any large alignment) that are
> both 8 bytes (or anything significantly smaller than a page). It is
> fundamentally impossible to put those note sections in the same PT_NOTE
> segment. You can minimize the number of PT_LOAD segments by first sorting
> as in this change then emitting a PT_NOTE segment when the next one won't
> be at the expected 4-byte aligned location.
>
> Ignoring the alignment require is possible but it means that sometimes
> unaligned reads will occur right?
>
> On Mon, Mar 11, 2019 at 9:20 AM Rui Ueyama <ruiu at google.com> wrote:
>
>> On Mon, Mar 11, 2019 at 3:09 AM Peter Smith via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> peter.smith added a comment.
>>>
>>> I personally favour a separate PT_NOTE section per alignment, that gives
>>> a note parser simple rule to iterate through the section (the p_align
>>> field). I think ordering by decreasing alignment will work in practice for
>>> the note sections that we have now, but it may not be in the future. I also
>>> think that this is worth doing even if clang is changed to generate
>>> .note.gnu.property sections that are 4-byte aligned; clang will often use
>>> libraries compiled by gcc (or some other compiler) that does use 8-byte
>>> aligned sections.
>>>
>>
>> I'm not sure if a separate PT_NOTE section per alignment would work for
>> all cases. I don't think the size of a note section with 8-byte alignment
>> is guaranteed to be a multiple of 8 byte. If that's permitted, there is a
>> gap after a note section whose size is not a multiple of 8. So I guess the
>> "most" correct approach would be to create a note segment for each note
>> section. But perhaps I'm overthinking now...
>>
>> There is a long glibc thread that covers a similar discussion in the gnu
>>> community https://sourceware.org/ml/libc-alpha/2018-08/msg00340.html ,
>>> it is quite long so I've pulled out a few bits of it here:
>>>
>>> - https://sourceware.org/ml/libc-alpha/2018-08/msg00344.html and
>>> follow-up https://sourceware.org/ml/libc-alpha/2018-08/msg00347.html on
>>> why two separate PT_NOTE sections were needed.
>>> - https://sourceware.org/ml/libc-alpha/2018-08/msg00468.html rejection
>>> of changing ld bfd to that of gold and just setting the alignment of
>>> .gnu.property to 4-bytes. Ostensibly due to presence of large number of
>>> binaries with 8-byte aligned sections.
>>>
>>> From what I can tell:
>>>
>>> - ld.bfd outputs a separate PT_NOTE per p_align.
>>> - ld.gold ignores the 8-byte alignment of the .note.gnu.property in the
>>> input object and changes it to 4 so that only one PT_NOTE is required.
>>>
>>
>> If ignoring the alignment requirement would work in practice, it is a
>> tempting choice.
>>
>>
>>> - glibc works for both, given that .note.gnu.property doesn't strictly
>>> need 8 byte alignment.
>>>
>>>
>>> Repository:
>>>   rLLD LLVM Linker
>>>
>>> CHANGES SINCE LAST ACTION
>>>   https://reviews.llvm.org/D59120/new/
>>>
>>> https://reviews.llvm.org/D59120
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190311/8c84dff2/attachment.html>