[ELF][ARM] Add Arm ABI names for float ABI ELF Header flags

[peter.smith]

Summary

The ELF for the Arm architecture document defines, for EF_ARM_EABI_VER5 and above, the flags EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT. These have been defined to be compatible with the existing EF_ARM_VFP_FLOAT and EF_ARM_SOFT_FLOAT used by gcc for EF_ARM_EABI_UNKNOWN.

This patch adds the flags in addition to the existing ones so that any code depending on the old names will still work. To my knowledge nothing in the existing LLVM codebase uses the old names. I would like to use the new ones in a LLD patch.

Reference:
Elf for the Arm Architecture section 4.2 Elf Header http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

[emaste]

LGTM. I made the same change in FreeBSD r336745.

[kettenis]

LGTM

[stefson]

hey there, I've run into problems with stripping static-libs on arm when using llvm/clang-7. Could you imagine this patch being at fault?

strip: armv7a-unknown-linux-gnueabihf-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   lib/libbz2.so.1.0.6
   usr/bin/bzip2recover
   bin/bzip2
   usr/lib/libbz2.a
armv7a-unknown-linux-gnueabihf-strip: /var/tmp/portage/app-arch/bzip2-1.0.6-r10/image/usr/lib/stImUpsE/bzlib.o: Failed to find link section for section 11
armv7a-unknown-linux-gnueabihf-strip: /var/tmp/portage/app-arch/bzip2-1.0.6-r10/image/usr/lib/stImUpsE/bzlib.o: Failed to find link section for section 11

Section 11 is: [11] .llvm_addrsig LOOS+0xfff4c03 00000000 003de4 000002 00 E 0 0 1

this didn't happen with llvm/clang-6, and the patch got commited within the fitting time frame?

[peter.smith]

In D49992#1267881, @stefson wrote:

hey there, I've run into problems with stripping static-libs on arm when using llvm/clang-7. Could you imagine this patch being at fault?

strip: armv7a-unknown-linux-gnueabihf-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   lib/libbz2.so.1.0.6
   usr/bin/bzip2recover
   bin/bzip2
   usr/lib/libbz2.a
armv7a-unknown-linux-gnueabihf-strip: /var/tmp/portage/app-arch/bzip2-1.0.6-r10/image/usr/lib/stImUpsE/bzlib.o: Failed to find link section for section 11
armv7a-unknown-linux-gnueabihf-strip: /var/tmp/portage/app-arch/bzip2-1.0.6-r10/image/usr/lib/stImUpsE/bzlib.o: Failed to find link section for section 11

Section 11 is: [11] .llvm_addrsig LOOS+0xfff4c03 00000000 003de4 000002 00 E 0 0 1

this didn't happen with llvm/clang-6, and the patch got commited within the fitting time frame?

There are quite a lot of patches that will have been committed within the clang 7 release. Please don't ping every one of them!

Thanks for posting Section 11. The address significance tables were introduced so that identical code folding can safely not fold functions that have a significant address. These were introduced in a variety of patches, one of which is https://reviews.llvm.org/D48155, I suggest searching for llvm address significance to find the rest. The thread to introduce them can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html

My guess is that the strip binary that you are using doesn't understand what a .llvm-addrsig is and is not expecting it to have a sh_link

llvm/trunk/include/llvm/BinaryFormat/ELF.h

 
 // ELF Relocation types for AArch64
 enum {
 #include "ELFRelocs/AArch64.def"
 };
 
 // ARM Specific e_flags
 enum : unsigned {
-  EF_ARM_SOFT_FLOAT = 0x00000200U,
-  EF_ARM_VFP_FLOAT = 0x00000400U,
+  EF_ARM_SOFT_FLOAT = 0x00000200U,     // Legacy pre EABI_VER5
+  EF_ARM_ABI_FLOAT_SOFT = 0x00000200U, // EABI_VER5
+  EF_ARM_VFP_FLOAT = 0x00000400U,      // Legacy pre EABI_VER5
+  EF_ARM_ABI_FLOAT_HARD = 0x00000400U, // EABI_VER5
   EF_ARM_EABI_UNKNOWN = 0x00000000U,
   EF_ARM_EABI_VER1 = 0x01000000U,
   EF_ARM_EABI_VER2 = 0x02000000U,
   EF_ARM_EABI_VER3 = 0x03000000U,
   EF_ARM_EABI_VER4 = 0x04000000U,
   EF_ARM_EABI_VER5 = 0x05000000U,
   EF_ARM_EABIMASK = 0xFF000000U
 };