summaryrefslogtreecommitdiff
path: root/config/arch/arm.in.2
diff options
context:
space:
mode:
Diffstat (limited to 'config/arch/arm.in.2')
-rw-r--r--config/arch/arm.in.231
1 files changed, 31 insertions, 0 deletions
diff --git a/config/arch/arm.in.2 b/config/arch/arm.in.2
index e871cc2..4d7504a 100644
--- a/config/arch/arm.in.2
+++ b/config/arch/arm.in.2
@@ -46,6 +46,37 @@ config ARCH_ARM_EABI
help
Set up the toolchain so that it generates EABI-compliant binaries.
+config ARCH_ARM_TUPLE_USE_EABIHF
+ bool
+ prompt "append 'hf' to the tuple (EXPERIMENTAL)"
+ depends on ARCH_FLOAT_HW
+ depends on ARCH_ARM_EABI # Until we only support that...
+ depends on EXPERIMENTAL
+ help
+ Is you say 'y' here, then the tuple for the toolchain will end
+ up with *eabihf, instead of the usual *eabi.
+
+ *eabihf is used to denote that the toolchain *is* using the
+ hard-float ABI, while *eabi is just an indication of using the
+ soft-float ABI.
+
+ Ie. all one can say is: *eabihf ⊢ hard-float ABI
+
+ Saying 'n' here does *not* impact the ability of the toolchain to
+ generate hard-float instructions with the hard-float ABI. It is a
+ purely cosmetic thing, used by distros to differentiate their
+ hard-float-ABI-using ports from their soft-float-ABI-using ports.
+ (eg. Debian Wheezy and above).
+
+ This is an option, as not all versions of gcc/binutils do support
+ such tuple, and fail to build with *eabihf. Stock gcc version up
+ to, and including 4.7.2 have an issue or another with *eabihf.
+
+ This option is here for the future.
+
+ Say 'n', unless you are trying to fix gcc to properly recognise
+ the *eabihf tuples.
+
config ARCH_ARM_ABI_OK
bool
default y