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

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 11 03:09:37 PDT 2019


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.

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





More information about the llvm-commits mailing list