This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |