[PATCH 1 of 1] gcc: support 'softfp' toolchains for ARM

[Benoît THÉBAUDEAU]

Hi Javier, Yann, all,

> gcc: support 'softfp' toolchains for ARM
>
> Allows to build toolchains with default '-mfloat-abi=softfp
> -mfpu=...'.

Good idea. Until now, I used to add extra config options when I needed softfp on
ARM.

But you handle only the softfp case, although the hard case also does not
produce any options (only the soft case did before your patch). Do you think the
hard case would be worth adding, or should the softfp/hard choice be left up to
the toolchain defaults if ARCH_FLOAT_HW=y? I wonder if the softfp/hard case had
not been dropped on purpose by Yann to avoid some issues on non-ARM targets.

[*---SNIP---*]
> diff -r a171c274bc12 -r 3d480b953bf8 config/target.in
> --- a/config/target.in	Tue Aug 30 19:38:10 2011 +0200
> +++ b/config/target.in	Wed Aug 31 17:55:12 2011 +0200
[*---SNIP---*]
> @@ -271,6 +277,11 @@
>        If your processor has no FPU, then you most probably want
>        this, as it
>        is faster than emulating the FPU in the kernel.
>
> +config ARCH_FLOAT_SOFTFP
> +    bool
> +    prompt "softfp"
> +    depends on ARCH_SUPPORT_SOFTFP
> +
>  endchoice
>
>  config TARGET_CFLAGS

Some help message would probably be useful for this option, something close to
the help message of ARCH_FLOAT_HW, stressing the fact that only the float ABI
will differ from the true hard option (which is not necessarily ARCH_FLOAT_HW
depending on the toolchain defaults as I explained above).

> diff -r a171c274bc12 -r 3d480b953bf8 scripts/build/arch/arm.sh
> --- a/scripts/build/arch/arm.sh	Tue Aug 30 19:38:10 2011 +0200
> +++ b/scripts/build/arch/arm.sh	Wed Aug 31 17:55:12 2011 +0200
> @@ -4,6 +4,9 @@
>      # The architecture part of the tuple:
>      CT_TARGET_ARCH="${CT_ARCH}${target_endian_eb}"
>
> +    # gcc ./configure flags
> +    [ "${CT_ARCH_FLOAT_SOFTFP}" ] && {
> CT_ARCH_FLOAT_CFLAG="-mfloat-abi=softfp";
> CT_ARCH_WITH_FLOAT="--with-float=softfp"; }
> +
>      # The system part of the tuple:
>      case "${CT_LIBC},${CT_ARCH_ARM_EABI}" in
>          *glibc,y)   CT_TARGET_SYS=gnueabi;;

Why not moving that to scripts/functions, below CT_ARCH_FLOAT_SW, as the softfp
option may be supported on other targets in the future?

Do you think the writing of the softfp choice would differ between targets?

> diff -r a171c274bc12 -r 3d480b953bf8
> scripts/build/libc/glibc-eglibc.sh-common
> --- a/scripts/build/libc/glibc-eglibc.sh-common	Tue Aug 30 19:38:10
> 2011 +0200
> +++ b/scripts/build/libc/glibc-eglibc.sh-common	Wed Aug 31 17:55:12
> 2011 +0200
> @@ -132,9 +132,9 @@
>          *) extra_config+=("--disable-shared");;
>      esac
>
> -    case "${CT_ARCH_FLOAT_HW},${CT_ARCH_FLOAT_SW}" in
> -        y,) extra_config+=("--with-fp");;
> -        ,y) extra_config+=("--without-fp");;
> +    case
> "${CT_ARCH_FLOAT_HW},${CT_ARCH_FLOAT_SW},${CT_ARCH_FLOAT_SOFTFP}" in
> +        y,,) extra_config+=("--with-fp");;
> +        ,y,|,,y) extra_config+=("--without-fp");;
>      esac
>
>      if [ "${CT_LIBC_DISABLE_VERSIONING}" = "y" ]; then

I think that's wrong. I have looked at eglibc's sources, and all it does with
"--with-fp" is use floating-point types. Hence, as softfp uses the FPU
opcodes, it would be a shame not to benefit from them here.

Or did you do that on purpose in order to avoid ABI compatibility issues?
softfp is much less interesting if the libc does not use it everywhere it
can. The only thing to make sure here is that the libc will not produce
hard-float ABI code if softfp is selected and "--with-fp" is used, which
could happen if there are hand-written assembly files in the libc.

> diff -r a171c274bc12 -r 3d480b953bf8 scripts/build/libc/uClibc.sh
> --- a/scripts/build/libc/uClibc.sh	Tue Aug 30 19:38:10 2011 +0200
> +++ b/scripts/build/libc/uClibc.sh	Wed Aug 31 17:55:12 2011 +0200
> @@ -352,13 +352,13 @@
>
>      # Accomodate for old and new uClibc version, where the
>      # way to select between hard/soft float has changed
> -    case "${CT_ARCH_FLOAT_HW},${CT_ARCH_FLOAT_SW}" in
> -        y,) cat <<-ENDSED
> +    case
> "${CT_ARCH_FLOAT_HW},${CT_ARCH_FLOAT_SW},${CT_ARCH_FLOAT_SOFTFP}" in
> +        y,,) cat <<-ENDSED
>  				s/^[^_]*(HAS_FPU).*/\\1=y/
>  				s/.*(UCLIBC_HAS_FPU).*/\\1=y/
>  				ENDSED
>              ;;
> -        ,y) cat <<-ENDSED
> +        ,y,|,,y) cat <<-ENDSED
>  				s/^[^_]*(HAS_FPU).*/\\# \\1 is not set/
>  				s/.*(UCLIBC_HAS_FPU).*/# \\1 is not set/
>  				ENDSED

I don't know what uClibc does with this option, but the same comment as
above for the libc applies here.

Apart from that, sounds good to me.

Best regards,
Benoît THÉBAUDEAU

--
For unsubscribe information see http://sourceware.org/lists.html#faq