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

[Jake Ehrlich via llvm-commits]

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/b4e97141/attachment-0001.html>