[libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

[mstorsjo]

Summary

This allows using dwarf exceptions on MinGW/ARM. This goes together with D39532 in LLVM and D39533 in clang.

[compnerd]

src/UnwindRegistersRestore.S

396 ↗

(On Diff #121245)

This really isn't an ELF vs COFF/Mach-O thing. Does MASM let you do something similar? This should at the very least be !defined(_WIN32). The same throughout.

[mstorsjo]

src/UnwindRegistersRestore.S

396 ↗

(On Diff #121245)

MASM is only for x86, and MS armasm uses a wholly different syntax (with afaik nothing similar to .arch or .fpu).

And similarly, if you try assembling a file with this directive, it will fail both for iOS and windows:

$ cat test.s
.text
.fpu vfpv3-d16
add r0, r0, r0
$ clang -target armv7-linux-gnueabi test.s -c -o test.o
$ clang -target armv7-apple-darwin test.s -c -o test.o
test.s:2:1: error: unknown directive
.fpu vfpv3-d16
^
$ clang -target thumbv7-win32-gnu test.s -c -o test.o
test.s:2:1: error: unknown directive
.fpu vfpv3-d16
^

[mstorsjo]

src/UnwindRegistersRestore.S

396 ↗

(On Diff #121245)

If you really wanted to, I could make it !defined(__APPLE__) && !defined(_WIN32), but I really think defined(__ELF__) is more straightforward. (The corresponding parts in the asm parser in LLVM is within an if (!IsMachO && !IsCOFF) block though.)

[compnerd]

Very well, if thats the current implementation in the AsmParser, thats reasonable. I don't think that the directive has anything to do with the file format though.

[mstorsjo]

In D39534#915916, @compnerd wrote:

Very well, if thats the current implementation in the AsmParser, thats reasonable. I don't think that the directive has anything to do with the file format though.

I can agree with that. In addition to making the assembler accept/reject certain instructions though, it actually does another thing which actually is file format specific - it sets the eabi attributes that indicates that the object file contains such instructions.

[jroelofs]

In D39534#915920, @mstorsjo wrote:

In D39534#915916, @compnerd wrote:

Very well, if thats the current implementation in the AsmParser, thats reasonable. I don't think that the directive has anything to do with the file format though.

I can agree with that. In addition to making the assembler accept/reject certain instructions though, it actually does another thing which actually is file format specific - it sets the eabi attributes that indicates that the object file contains such instructions.

Are they eabi/gnueabi things?

[mstorsjo]

In D39534#915935, @jroelofs wrote:

In D39534#915920, @mstorsjo wrote:

In D39534#915916, @compnerd wrote:

Very well, if thats the current implementation in the AsmParser, thats reasonable. I don't think that the directive has anything to do with the file format though.

I can agree with that. In addition to making the assembler accept/reject certain instructions though, it actually does another thing which actually is file format specific - it sets the eabi attributes that indicates that the object file contains such instructions.

Are they eabi/gnueabi things?

I think so. You can read them with readelf -A foo.o, and override them with manual .eabi_attribute attributes. (That's useful e.g. for indicating that while a binary contains NEON instructions, it doesn't strict require them for running. E.g. raspbian does check such tags for checking that all binaries work on their baseline of armv6.)

[jroelofs]

In D39534#915937, @mstorsjo wrote:

In D39534#915935, @jroelofs wrote:

In D39534#915920, @mstorsjo wrote:

In D39534#915916, @compnerd wrote:

Very well, if thats the current implementation in the AsmParser, thats reasonable. I don't think that the directive has anything to do with the file format though.

I can agree with that. In addition to making the assembler accept/reject certain instructions though, it actually does another thing which actually is file format specific - it sets the eabi attributes that indicates that the object file contains such instructions.

Are they eabi/gnueabi things?

I think so. You can read them with readelf -A foo.o, and override them with manual .eabi_attribute attributes. (That's useful e.g. for indicating that while a binary contains NEON instructions, it doesn't strict require them for running. E.g. raspbian does check such tags for checking that all binaries work on their baseline of armv6.)

i.e. should this be keyed off of __ARM_EABI__ instead?

[mstorsjo]

In D39534#915938, @jroelofs wrote:

i.e. should this be keyed off of __ARM_EABI__ instead?

I'm not really sure. As I quoted earlier, the exact case for enabling these directives in the LLVM codebase right now is (!IsMachO && !IsCOFF).

We could make this !defined(__MACH__) && !defined(_WIN32), but I felt that defined(__ELF__) was more readable.

I'm not familiar enough with the other ARM configurations to know what makes most sense for them. Which ones might I be missing here - non-EABI ELF configurations, or non-ELF EABI configurations, or both? If it's non-EABI ELF configurations, the current directive should be fine I think.

libunwind/trunk/docs/index.rst

 Any          i386, x86_64, ARM    Clang        SjLj
 Bare Metal   ARM                  Clang, GCC   EHABI
 FreeBSD      i386, x86_64, ARM64  Clang        DWARF CFI
 iOS          ARM                  Clang        SjLj
 Linux        ARM                  Clang, GCC   EHABI
 Linux        i386, x86_64, ARM64  Clang, GCC   DWARF CFI
 Mac OS X     i386, x86_64         Clang, GCC   DWARF CFI
 NetBSD       x86_64               Clang, GCC   DWARF CFI
-Windows      i386, x86_64         Clang        DWARF CFI
+Windows      i386, x86_64, ARM    Clang        DWARF CFI
 ============ ==================== ============ ========================
 
 The following minimum compiler versions are strongly recommended.
 
 * Clang 3.5 and above
 * GCC 4.7 and above.
 
 Anything older *may* work.

libunwind/trunk/src/UnwindRegistersRestore.S

 
 @
 @ static void libunwind::Registers_arm::restoreVFPWithFLDMD(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3-d16
+#endif
 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}
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::restoreVFPWithFLDMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3-d16
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreVFPWithFLDMXEPy)
   vldmia r0, {d0-d15} @ fldmiax is deprecated in ARMv7+ and now behaves like vldmia
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::restoreVFPv3(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm12restoreVFPv3EPy)
   vldmia r0, {d16-d31}
   JMP(lr)
 
 #if defined(__ARM_WMMX)
 
 @
 @ static void libunwind::Registers_arm::restoreiWMMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .arch armv5te
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm12restoreiWMMXEPy)
   ldcl p1, cr0, [r0], #8  @ wldrd wR0, [r0], #8
   ldcl p1, cr1, [r0], #8  @ wldrd wR1, [r0], #8
   ldcl p1, cr2, [r0], #8  @ wldrd wR2, [r0], #8
   ldcl p1, cr3, [r0], #8  @ wldrd wR3, [r0], #8
   ldcl p1, cr4, [r0], #8  @ wldrd wR4, [r0], #8
   ldcl p1, cr5, [r0], #8  @ wldrd wR5, [r0], #8
   ldcl p1, cr6, [r0], #8  @ wldrd wR6, [r0], #8

 
 @
 @ static void libunwind::Registers_arm::restoreiWMMXControl(unw_uint32_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .arch armv5te
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj)
   ldc2 p1, cr8, [r0], #4  @ wldrw wCGR0, [r0], #4
   ldc2 p1, cr9, [r0], #4  @ wldrw wCGR1, [r0], #4
   ldc2 p1, cr10, [r0], #4  @ wldrw wCGR2, [r0], #4
   ldc2 p1, cr11, [r0], #4  @ wldrw wCGR3, [r0], #4
   JMP(lr)
 
 #endif

libunwind/trunk/src/UnwindRegistersSave.S

 
 @
 @ static void libunwind::Registers_arm::saveVFPWithFSTMD(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3-d16
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveVFPWithFSTMDEPy)
   vstmia r0, {d0-d15}
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::saveVFPWithFSTMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3-d16
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveVFPWithFSTMXEPy)
   vstmia r0, {d0-d15} @ fstmiax is deprecated in ARMv7+ and now behaves like vstmia
   JMP(lr)
 
 @
 @ static void libunwind::Registers_arm::saveVFPv3(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .fpu vfpv3
+#endif
 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}
   JMP(lr)
 
 #if defined(_LIBUNWIND_ARM_WMMX)
 
 @
 @ static void libunwind::Registers_arm::saveiWMMX(unw_fpreg_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .arch armv5te
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm9saveiWMMXEPy)
   stcl p1, cr0, [r0], #8  @ wstrd wR0, [r0], #8
   stcl p1, cr1, [r0], #8  @ wstrd wR1, [r0], #8
   stcl p1, cr2, [r0], #8  @ wstrd wR2, [r0], #8
   stcl p1, cr3, [r0], #8  @ wstrd wR3, [r0], #8
   stcl p1, cr4, [r0], #8  @ wstrd wR4, [r0], #8
   stcl p1, cr5, [r0], #8  @ wstrd wR5, [r0], #8
   stcl p1, cr6, [r0], #8  @ wstrd wR6, [r0], #8

 
 @
 @ static void libunwind::Registers_arm::saveiWMMXControl(unw_uint32_t* values)
 @
 @ On entry:
 @  values pointer is in r0
 @
   .p2align 2
+#if defined(__ELF__)
   .arch armv5te
+#endif
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveiWMMXControlEPj)
   stc2 p1, cr8, [r0], #4  @ wstrw wCGR0, [r0], #4
   stc2 p1, cr9, [r0], #4  @ wstrw wCGR1, [r0], #4
   stc2 p1, cr10, [r0], #4  @ wstrw wCGR2, [r0], #4
   stc2 p1, cr11, [r0], #4  @ wstrw wCGR3, [r0], #4
   JMP(lr)
 
 #endif