1.1 --- a/config/arch/arm.in.2 Wed Jan 09 18:52:15 2013 +0100
1.2 +++ b/config/arch/arm.in.2 Thu Jan 10 00:11:17 2013 +0100
1.3 @@ -46,6 +46,37 @@
1.4 help
1.5 Set up the toolchain so that it generates EABI-compliant binaries.
1.6
1.7 +config ARCH_ARM_TUPLE_USE_EABIHF
1.8 + bool
1.9 + prompt "append 'hf' to the tuple (EXPERIMENTAL)"
1.10 + depends on ARCH_FLOAT_HW
1.11 + depends on ARCH_ARM_EABI # Until we only support that...
1.12 + depends on EXPERIMENTAL
1.13 + help
1.14 + Is you say 'y' here, then the tuple for the toolchain will end
1.15 + up with *eabihf, instead of the usual *eabi.
1.16 +
1.17 + *eabihf is used to denote that the toolchain *is* using the
1.18 + hard-float ABI, while *eabi is just an indication of using the
1.19 + soft-float ABI.
1.20 +
1.21 + Ie. all one can say is: *eabihf ⊢ hard-float ABI
1.22 +
1.23 + Saying 'n' here does *not* impact the ability of the toolchain to
1.24 + generate hard-float instructions with the hard-float ABI. It is a
1.25 + purely cosmetic thing, used by distros to differentiate their
1.26 + hard-float-ABI-using ports from their soft-float-ABI-using ports.
1.27 + (eg. Debian Wheezy and above).
1.28 +
1.29 + This is an option, as not all versions of gcc/binutils do support
1.30 + such tuple, and fail to build with *eabihf. Stock gcc version up
1.31 + to, and including 4.7.2 have an issue or another with *eabihf.
1.32 +
1.33 + This option is here for the future.
1.34 +
1.35 + Say 'n', unless you are trying to fix gcc to properly recognise
1.36 + the *eabihf tuples.
1.37 +
1.38 config ARCH_ARM_ABI_OK
1.39 bool
1.40 default y
2.1 --- a/scripts/build/arch/arm.sh Wed Jan 09 18:52:15 2013 +0100
2.2 +++ b/scripts/build/arch/arm.sh Thu Jan 10 00:11:17 2013 +0100
2.3 @@ -24,4 +24,8 @@
2.4 if [ "${CT_ARCH_ARM_INTERWORKING}" = "y" ]; then
2.5 CT_ARCH_TARGET_CFLAGS+=" -mthumb-interwork"
2.6 fi
2.7 +
2.8 + if [ "${CT_ARCH_ARM_TUPLE_USE_EABIHF}" = "y" ]; then
2.9 + CT_TARGET_SYS="${CT_TARGET_SYS}hf"
2.10 + fi
2.11 }