[PATCH] D59531: [ELF] Produce multiple PT_NOTE segments as needed

Tue May 7 01:44:29 PDT 2019

MaskRay added a comment.

In D59531#1492971 <https://reviews.llvm.org/D59531#1492971>, @ruiu wrote:

> I'm still thinking that overriding .note section alignment with 4 is the best way to fix the issue. Setting it to 8 is a tool's bug, and fundamentally the .note section format does not seem to be designed to accommodate something whose alignment requirement is greater than 4 exactly because of this issue.

@ruiu Sorry for being hurry (D61296 <https://reviews.llvm.org/D61296>). Forcing p_align=4 doesn't work if some systems interpret notes according to the alignment, as a sequence of `Elf64_Word`s or a sequence of `Elf64_Xword`s (suggested by some people in https://groups.google.com/forum/#!searchin/generic-abi/SHT_NOTE%7Csort:date/generic-abi/TRJYlEklEfM/Wrz-0kXOAgAJ)

When systems started to move towards 64 bits, HP-UX followed gABI and used 8-byte alignment (`Elf64_Xword n_namesz, n_descsz, n_type;`. This is probably not what they actually use but the struct definition here eases thinking). Many (including Linux, Solaris, NetBSD) diverged (`Elf64_Word n_namesz, n_descsz, n_type;`). We can't blame them much, the gABI description isn't so clear about the caveat.

On these systems, some notes are established and can't be changed (.note.ABI-tag .note.gnu.build-id). Some newly invented (including .note.gnu.property) notes start to use 8-byte alignment. When a 4-byte aligned note is followed by an 8-byte aligned note, the interpretation of the 8-byte aligned note may be difficult: some consumers may expect a padding while some may not.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59531/new/

https://reviews.llvm.org/D59531