[libunwind][ARM] Fix VFP build attribute for context save/restore code

[olista01]

Summary

These files use VSTM and VLDM instructions to save and restore the
floating-point registers, so the assembler emits the Tag_FP_arch build
attribute, so the resulting object can not be linked for a CPU which
does not have a floating-point unit. This would actually be safe,
because these functions will only be called if the FP registers are
listed in the unwind tables, which can only happen if some other
floating-point code is linked in.

Instead, we need to directly use the encodings of the instructions with
the .inst (or .inst.w) directive.

[rengolin]

what about BE32?

[olista01]

clang and gas both emit the correct mapping symbols for the .inst directive, so the object file will be the same except for the build attribute.

[rengolin]

Right. I *really* dislike using the inst directive, but I have no better ideas.

Though, I'd rather @compnerd and @jroelofs could have a look first.

Thanks!

[compnerd]

src/UnwindRegistersRestore.S

374

Cant we get away with .feature? IIRC, that doesn't propagate into the build attributes (it is meant for use in such a situation).

[olista01]

src/UnwindRegistersRestore.S

374

Is that an assembler directive? Neither LLVM nor GAS accept it, and I can't find any mention of it in the LLVM source or GAS docs.

[compnerd]

Ugh, sorry, its spelt .arch_extension, which takes the feature you want to enable.

[olista01]

.arch_extension only accepts a limited set of architectural extensions, not LLVM target features. There is an "fp" extension, but this refers to the fp-armv8 extension, and requires that the target is currently armv8-a.

[rengolin]

In D22464#516381, @olista01 wrote:

.arch_extension only accepts a limited set of architectural extensions, not LLVM target features. There is an "fp" extension, but this refers to the fp-armv8 extension, and requires that the target is currently armv8-a.

Weird. It should support "vfpN" and "neon", too. If not, this is a bug in the target parser or the ARM back-end.

src/UnwindRegistersRestore.S

DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind15Registers_arm646jumptoEv)
 
   ldp    x0, x1,  [x0, #0x000]  // restore x0,x1
   ret    x30                    // jump to pc
 
 #elif defined(__arm__) && !defined(__APPLE__)
 
 #if !defined(__ARM_ARCH_ISA_ARM)
   .thumb
+#define INST_W .inst.w
+#else
+  .arm
+#define INST_W .inst
 #endif
 
 @
 @ void libunwind::Registers_arm::restoreCoreAndJumpTo()
 @
 @ On entry:
 @  thread_state pointer is in r0
 @

 
 @
 @ static void libunwind::Registers_arm::restoreVFPWithFLDMD(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3-d16
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreVFPWithFLDMDEPy)
-  @ VFP and iwMMX instructions are only available when compiling with the flags
-  @ that enable them. We do not want to do that in the library (because we do not
-  @ want the compiler to generate instructions that access those) but this is
-  @ only accessed if the personality routine needs these registers. Use of
-  @ these registers implies they are, actually, available on the target, so
-  @ it's ok to execute.
-  @ So, generate the instruction using the corresponding coprocessor mnemonic.
-  vldmia r0, {d0-d15}
+@ Here, we use .inst (or .inst.w) to encode the floating-point operations. This
+@ avoids clang setting the build attribute for floating-point hardware, meaning
+@ that this library can still be linked for and run on a CPU with no FPU. This
+@ is safe, as these functions will not be called unless the VFP registers are
+@ mentioned in the unwind tables. The encodings of these instructions are the
+@ same for ARM and Thumb2, these do not need to be valid instructions for Thumb1
+@ as they can never be called on a Thumb1-only CPU.
+@ vldmia r0, {d0-d15}
+  INST_W 0xec900b20
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::restoreVFPWithFLDMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3-d16
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreVFPWithFLDMXEPy)
-  vldmia r0, {d0-d15} @ fldmiax is deprecated in ARMv7+ and now behaves like vldmia
+@ vldmia r0, {d0-d15} @ fldmiax is deprecated in ARMv7+ and now behaves like vldmia
+  INST_W 0xec900b20
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::restoreVFPv3(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm12restoreVFPv3EPy)
-  vldmia r0, {d16-d31}
+@ vldmia r0, {d16-d31}
+  INST_W 0xecd00b20
   JMP(lr)
 
 #if defined(__ARM_WMMX)
 
 @
 @ static void libunwind::Registers_arm::restoreiWMMX(unw_fpreg_t* values)
 @
 @ On entry:

src/UnwindRegistersSave.S

DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
   str    d31,     [x0, #0x208]
   mov    x0, #0                   // return UNW_ESUCCESS
   ret
 
 #elif defined(__arm__) && !defined(__APPLE__)
 
 #if !defined(__ARM_ARCH_ISA_ARM)
   .thumb
+#define INST_W .inst.w
+#else
+#define INST_W .inst
 #endif
 
 @
 @ extern int unw_getcontext(unw_context_t* thread_state)
 @
 @ On entry:
 @  thread_state pointer is in r0
 @ 

 
 @
 @ static void libunwind::Registers_arm::saveVFPWithFSTMD(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3-d16
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveVFPWithFSTMDEPy)
-  vstmia r0, {d0-d15}
+@
+@ Here, we use .inst (or .inst.w) to encode the floating-point operations. This
+@ avoids clang setting the build attribute for floating-point hardware, meaning
+@ that this library can still be linked for and run on a CPU with no FPU. This
+@ is safe, as these functions will not be called unless the VFP registers are
+@ mentioned in the unwind tables. The encodings of these instructions are the
+@ same for ARM and Thumb2, these do not need to be valid instructions for Thumb1
+@ as they can never be called on a Thumb1-only CPU.
+@
+@ vstmia r0, {d0-d15}
+  INST_W 0xec800b20
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::saveVFPWithFSTMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3-d16
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveVFPWithFSTMXEPy)
-  vstmia r0, {d0-d15} @ fstmiax is deprecated in ARMv7+ and now behaves like vstmia
+@ vstmia r0, {d0-d15} @ fstmiax is deprecated in ARMv7+ and now behaves like vstmia
+  INST_W 0xec800b20
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::saveVFPv3(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
-  .fpu vfpv3
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm9saveVFPv3EPy)
-  @ VFP and iwMMX instructions are only available when compiling with the flags
-  @ that enable them. We do not want to do that in the library (because we do not
-  @ want the compiler to generate instructions that access those) but this is
-  @ only accessed if the personality routine needs these registers. Use of
-  @ these registers implies they are, actually, available on the target, so
-  @ it's ok to execute.
-  @ So, generate the instructions using the corresponding coprocessor mnemonic.
-  vstmia r0, {d16-d31}
+@ vstmia r0, {d16-d31}
+  INST_W 0xecc00b20
   JMP(lr)
 
 #if defined(_LIBUNWIND_ARM_WMMX)
 
 @
 @ static void libunwind::Registers_arm::saveiWMMX(unw_fpreg_t* values)
 @
 @ On entry: