[ELF] Place SHT_NOTE sections with the same alignment into one PT_NOTE

[MaskRay]

Summary

While the generic ABI requires notes to be 8-byte aligned in ELF64, many
vendor-specific notes (from Linux, NetBSD, Solaris, etc) use 4-byte
alignment.

In a PT_NOTE segment, if 4-byte aligned notes are followed by an 8-byte
aligned note, the possible 4-byte padding may make consumers fail to
parse the 8-byte aligned note. See PR41000 for the recent report about
.note.gnu.property (NT_GNU_PROPERTY_TYPE_0).
(Note, for NT_GNU_PROPERTY_TYPE_0, the consumers should probably migrate
to PT_GNU_PROPERTY, but the alignment issue affects other notes as well.)

To fix the issue, this patches disallows notes with different alignments
from being placed in the same PT_NOTE. If compilers emit 4-byte aligned
notes before 8-byte aligned notes, we'll create at most 2 segments.

We don't have to check whether sh_size is a multiple of sh_addralign.
It is unrealistic and it shouldn't cause parsing issues anyway (the
output is not different from the case with the sh_size aligned up).

An alternative approach is to create a PT_NOTE for each SHT_NOTE, but
we'll have to incur the sizeof(Elf64_Phdr) = 56 overhead every time a
new note section is introduced.

[MaskRay]

Change descriptions a bit

[jakehehrlich]

If multiple note sections with unaligned sizes but larger than 4-byte alignment are used this solution doesn't work.

[MaskRay]

In D61296#1484755, @jakehehrlich wrote:

If multiple note sections with unaligned sizes but larger than 4-byte alignment are used this solution doesn't work.

I've mentioned this in the description.
First, alignments other than 4/8 are unrealistic.
Second, sh_size%sh_addralign!=0 is unrealistic. The rule for linking unrecognized sections is (linker doesn't know the semantics of many .note*):

Unrecognized sections that do not have the SHF_OS_NONCONFORMING attribute, are combined in a two-phase process. As the link editor combines sections using this process, it must honor the alignment constraints of the input sections (asserted by the sh_addralign field), padding between sections with zero bytes, if necessary, and producing a combination with the maximum alignment constraint of its component input sections.

Say you have a .note.a (sh_addralign=8 sh_size=9) followed by another .note.a (sh_addralign=8 sh_size=16). The size of the first note is not a multiple of the alignment. Since the two input sections have the same name, they are concatenated and go to the same output section. When concatenating, the linker will emit a 7-byte padding (as if `sh_addralign=8 sh_size=9+7). To guarantee the notes after linking are parsable, the compilers must take into account of this factor and emit size aligned notes to the object files.

[jakehehrlich]

Ok so I'm good with this. We would like to land this ASAP.

[MaskRay]

Update description

ELF/Writer.cpp

template <class ELFT> std::vector<PhdrEntry *> Writer<ELFT>::createPhdrs() {
 
   // PT_OPENBSD_WXNEEDED is a OpenBSD-specific header to mark the executable
   // is expected to perform W^X violations, such as calling mprotect(2) or
   // mmap(2) with PROT_WRITE | PROT_EXEC, which is prohibited by default on
   // OpenBSD.
   if (Config->ZWxneeded)
     AddHdr(PT_OPENBSD_WXNEEDED, PF_X);
 
-  // Create one PT_NOTE per a group of contiguous .note sections.
+  // Create one PT_NOTE per a group of contiguous SHT_NOTE sections with the
+  // same alignment.
   PhdrEntry *Note = nullptr;
   for (OutputSection *Sec : OutputSections) {
     if (Sec->Type == SHT_NOTE && (Sec->Flags & SHF_ALLOC)) {
-      if (!Note || Sec->LMAExpr)
+      if (!Note || Sec->LMAExpr || Note->LastSec->Alignment != Sec->Alignment)
         Note = AddHdr(PT_NOTE, PF_R);
       Note->add(Sec);
     } else {
       Note = nullptr;
     }
   }
   return Ret;
 }

test/ELF/build-id.s

 # ALIGN-NEXT: Size:
 # ALIGN-NEXT: Link:
 # ALIGN-NEXT: Info:
 # ALIGN-NEXT: AddressAlignment: 4
 
 # DEFAULT:      Contents of section .note.test:
 # DEFAULT:      Contents of section .note.gnu.build-id:
 # DEFAULT-NEXT: 04000000 08000000 03000000 474e5500  ............GNU.
-# DEFAULT-NEXT: 894c04e8 fbf5556b
+# DEFAULT-NEXT: 95849665 2621c734
 
 # MD5:      Contents of section .note.gnu.build-id:
 # MD5-NEXT: 04000000 10000000 03000000 474e5500  ............GNU.
-# MD5-NEXT: 6a51bbd7 9e8ee3f9 2e02d213 711cfec9
+# MD5-NEXT: 1882c01f 71698eed 229b3994 eb554c80
 
 # SHA1:      Contents of section .note.gnu.build-id:
 # SHA1-NEXT: 04000000 14000000 03000000 474e5500  ............GNU.
-# SHA1-NEXT: 9a8618b1 d6fd0e5c eda73dd8 76de5596
+# SHA1-NEXT: 96820adf d90d5470 0a0c32ff a88c4017
 
 # UUID:      Contents of section .note.gnu.build-id:
 # UUID-NEXT: 04000000 10000000 03000000 474e5500  ............GNU.
 
 # HEX:      Contents of section .note.gnu.build-id:
 # HEX-NEXT: 04000000 04000000 03000000 474e5500  ............GNU.
 # HEX-NEXT: 12345678
 
 # NONE-NOT: Contents of section .note.gnu.build-id:

test/ELF/note-alignment.s

+# REQUIRES: x86
+# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
+
+# RUN: ld.lld %t.o -o %t
+# RUN: llvm-readelf -l %t | FileCheck %s
+
+# CHECK: NOTE {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} 0x000004 0x000004 R   0x4
+# CHECK: NOTE {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} 0x000010 0x000010 R   0x8
+# CHECK: NOTE {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} {{0x[0-9a-f]+}} 0x000008 0x000008 R   0x4
+
+# CHECK:      03     .note.a
+# CHECK-NEXT: 04     .note.b .note.c
+# CHECK-NEXT: 05     .note.d .note.e
+
+.section .note.a, "a", @note
+.align 4
+.long 0
+
+.section .note.b, "a", @note
+.align 8
+.quad 0
+
+.section .note.c, "a", @note
+.align 8
+.quad 0
+
+.section .note.d, "a", @note
+.align 4
+.long 0
+
+.section .note.e, "a", @note
+.align 4
+.long 0