1.1 --- a/config/arch/arm.in.2	Wed Dec 26 20:05:19 2012 +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