[patch] fix libffi build on arm-linux-gnueabi with -mfloat-abi=softfp

View: New views
2 Messages — Rating Filter:   Alert me  

[patch] fix libffi build on arm-linux-gnueabi with -mfloat-abi=softfp

by Matthias Klose-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Based on the comments in PR41443:

All the references to __SOFTFP__ in this file are incorrect for EABI; the
__SOFTFP__ code should be used for *soft-float ABI* whether or not VFP is
enabled, and __SOFTFP__ does specifically mean soft-float not soft-float
ABI.

If you change the conditionals to __SOFTFP__ || __ARM_EABI__ then
-mfloat-abi=softfp should work.  -mfloat-abi=hard won't; that would need
both a new macro to identify the hard-VFP ABI, and new libffi code to
handle that ABI.

No regressions when running the libffi testsuite with and without
-mfloat-abi=softfp.

Ok for the trunk, ok for the branches (checking that the macros are available
there)?

   Matthias

2009-09-23  Matthias Klose  <doko@...>

        PR libffi/40242, PR libffi/41443
        * src/arm/sysv.S (__ARM_ARCH__): Define for processors
        __ARM_ARCH_6T2__, __ARM_ARCH_6M__, __ARM_ARCH_7__,
        __ARM_ARCH_7A__, __ARM_ARCH_7R__, __ARM_ARCH_7M__.
        Change the conditionals to __SOFTFP__ || __ARM_EABI__
        for -mfloat-abi=softfp to work.

Index: src/arm/sysv.S
===================================================================
--- src/arm/sysv.S (revision 152042)
+++ src/arm/sysv.S (working copy)
@@ -67,11 +67,18 @@
 
 #if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \
         || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) \
-        || defined(__ARM_ARCH_6ZK__)
+        || defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) \
+ || defined(__ARM_ARCH_6M__)
 # undef __ARM_ARCH__
 # define __ARM_ARCH__ 6
 #endif
 
+#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \
+        || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__)
+# undef __ARM_ARCH__
+# define __ARM_ARCH__ 7
+#endif
+
 #if __ARM_ARCH__ >= 5
 # define call_reg(x) blx x
 #elif defined (__ARM_ARCH_4T__)
@@ -189,7 +196,7 @@
 
 @ return INT
  cmp r3, #FFI_TYPE_INT
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
  cmpne r3, #FFI_TYPE_FLOAT
 #endif
  streq r0, [r2]
@@ -197,12 +204,12 @@
 
  @ return INT64
  cmp r3, #FFI_TYPE_SINT64
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
  cmpne r3, #FFI_TYPE_DOUBLE
 #endif
  stmeqia r2, {r0, r1}
 
-#ifndef __SOFTFP__
+#if !defined(__SOFTFP__) && !defined(__ARM_EABI__)
  beq LSYM(Lepilogue)
 
 @ return FLOAT
@@ -245,21 +252,21 @@
  beq .Lretint
 
  cmp r0, #FFI_TYPE_FLOAT
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
  beq .Lretint
 #else
  beq .Lretfloat
 #endif
 
  cmp r0, #FFI_TYPE_DOUBLE
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
  beq .Lretlonglong
 #else
  beq .Lretdouble
 #endif
 
  cmp r0, #FFI_TYPE_LONGDOUBLE
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
  beq .Lretlonglong
 #else
  beq .Lretlongdouble
@@ -278,7 +285,7 @@
  ldr r1, [sp, #4]
  b .Lclosure_epilogue
 
-#ifndef __SOFTFP__
+#if !defined(__SOFTFP__) && !defined(__ARM_EABI__)
 .Lretfloat:
  ldfs f0, [sp]
  b .Lclosure_epilogue

Re: [patch] fix libffi build on arm-linux-gnueabi with -mfloat-abi=softfp

by Andrew Haley :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matthias Klose wrote:

> Based on the comments in PR41443:
>
> All the references to __SOFTFP__ in this file are incorrect for EABI; the
> __SOFTFP__ code should be used for *soft-float ABI* whether or not VFP is
> enabled, and __SOFTFP__ does specifically mean soft-float not soft-float
> ABI.
>
> If you change the conditionals to __SOFTFP__ || __ARM_EABI__ then
> -mfloat-abi=softfp should work.  -mfloat-abi=hard won't; that would need
> both a new macro to identify the hard-VFP ABI, and new libffi code to
> handle that ABI.
>
> No regressions when running the libffi testsuite with and without
> -mfloat-abi=softfp.
>
> Ok for the trunk, ok for the branches (checking that the macros are
> available there)?

Yes, I think that's the right thing to do.

Andrew.