update the pr_datasz of .note.gnu.property section

[xiangzhangllvm]

Summary

System V Application Binary Interface
Linux Extensions
Version 0.1
Edited by
H.J. Lu1
September 18, 2018
.note.gnu.property
The program property array
Each array element represents one program property with type, data size and data.
In 64-bit objects, each element is an array of 8-byte integers in the format of the
target processor. In 32-bit objects, each element is an array of 4-byte integers in
the format of the target processor. An array element has the following structure:
typedef struct {
Elf_Word pr_type;
Elf_Word pr_datasz;
unsigned char pr_data[PR_DATASZ];
unsigned char pr_padding[PR_PADDING];
} Elf_Prop;
pr_type The type of program property. A 4-byte integer in the format of the
target processor.
pr_datasz The size of the pr_data field. A 4-byte integer in the format of the
target processor.
pr_data The program property descriptor which is aligned to 4 bytes in 32-bit
objects and 8 bytes in 64-bit objects.
pr_padding The padding. If necessary, it aligns the array element to 8 or 4-byte
alignment (depending on whether the file is a 64-bit or 32-bit object).
PR_DATASZ The value in the pr_datasz field. A constant.
PR_PADDING The size of the pr_padding field. A constant.

[xiangzhangllvm]

This data is also 4 in GCC

[vzakhari]

Please submit your patch with full context according to LLVM's documentation: https://www.llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

According to the documentation that you posted:
pr_datasz The size of the pr_data field. A 4-byte integer in the format of the target processor.
pr_data The program property descriptor which is aligned to 4 bytes in 32-bit objects and 8 bytes in 64-bit objects.

Line 576 emits WordSize bytes of data (which seems to be 8 bytes for x86-64), so why do you emit '4' for pr_datasz value?

[xiangzhangllvm]

hi vzakhari
The '4' for pr_datasz value will is fixed in the new ABI SPEC which will be modify by the reviewer hjl.tools, In fact, pr_datasz is already fixed 4 in GCC.
I have discussed this data with Hongjiu Lu who maintain the System V Application Binary Interface.

OutStreamer->EmitIntValue(FeatureFlagsAnd, WordSize); // data
Yes, here the WordSize this should change to 4 too, it will have problem in big-end system.

[xiangzhangllvm]

Thank you Zakharin!

[vzakhari]

lib/Target/X86/X86AsmPrinter.cpp

577 ↗

(On Diff #179990)

Good. Now everything except this line looks consistent.

If we make members 4-byte values why do we want to keep 8-byte alignment for x86-64? May I have a link to the proposed ABI change?

[xiangzhangllvm]

I think there may be a history reason, I just discuss it with Hongjiu Lu, he used to put SPEC here:
https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf

And In fact, In the 64-bit system,
here the pr_data size is 4 and the pr_data will always be 8 aligned because the alignment of section and its even (not odd) index in the section.

[vzakhari]

I think I got it, finally, after talking with HJ. As defined in https://github.com/hjl-tools/x86-psABI/blob/hjl/master/dl.tex, the pr_data field consists of 4-byte integers for GNU_PROPERTY_X86_FEATURE_1_AND program property type (pr_type). At the same time, the program property array must be a multiple of 8 bytes on x86-64 (as stated in https://github.com/hjl-tools/linux-abi/blob/hjl/master/object-files.tex), thus, the alignment is computed properly.

It looks good to me, but please align the comment on line 577 with the comment on the previous line.

[xiangzhangllvm]

Thank you Zakharin!
Could you please help me merge the patch to LLVM org?

llvm/trunk/lib/Target/X86/X86AsmPrinter.cpp

if (FeatureFlagsAnd) {
       EmitAlignment(WordSize == 4 ? 2 : 3);
       OutStreamer->EmitIntValue(4, 4 /*size*/); // data size for "GNU\0"
       OutStreamer->EmitIntValue(8 + WordSize, 4 /*size*/); // Elf_Prop size
       OutStreamer->EmitIntValue(ELF::NT_GNU_PROPERTY_TYPE_0, 4 /*size*/);
       OutStreamer->EmitBytes(StringRef("GNU", 4)); // note name
 
       // Emitting an Elf_Prop for the CET properties.
       OutStreamer->EmitIntValue(ELF::GNU_PROPERTY_X86_FEATURE_1_AND, 4);
-      OutStreamer->EmitIntValue(WordSize, 4);               // data size
-      OutStreamer->EmitIntValue(FeatureFlagsAnd, WordSize); // data
-      EmitAlignment(WordSize == 4 ? 2 : 3);                 // padding
+      OutStreamer->EmitIntValue(4, 4);               // data size
+      OutStreamer->EmitIntValue(FeatureFlagsAnd, 4); // data
+      EmitAlignment(WordSize == 4 ? 2 : 3);          // padding
 
       OutStreamer->endSection(Nt);
       OutStreamer->SwitchSection(Cur);
     }
   }
 
   if (TT.isOSBinFormatMachO())
     OutStreamer->SwitchSection(getObjFileLowering().getTextSection());

llvm/trunk/test/CodeGen/X86/note-cet-property.ll

 
 ; X86_64:      .section        .note.gnu.property,"a",@note
 ; X86_64-NEXT: .p2align 3
 ; X86_64-NEXT: .long    4
 ; X86_64-NEXT: .long    16
 ; X86_64-NEXT: .long    5
 ; X86_64-NEXT: .asciz   "GNU"
 ; X86_64-NEXT: .long    3221225474
-; X86_64-NEXT: .long    8
-; X86_64-NEXT: .quad    3
+; X86_64-NEXT: .long    4
+; X86_64-NEXT: .long    3
 ; X86_64-NEXT: .p2align 3
 
 !llvm.module.flags = !{!0, !1}
 
 !0 = !{i32 4, !"cf-protection-return", i32 1}
 !1 = !{i32 4, !"cf-protection-branch", i32 1}