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] |
On Thu, 2011-09-01 at 00:33 +0200, Yann E. MORIN wrote: > Javier, Benoît, All, > > On Wednesday 31 August 2011 21:37:21 Benoît THÉBAUDEAU wrote: > > > gcc: support 'softfp' toolchains for ARM > > > > > > Allows to build toolchains with default '-mfloat-abi=softfp > > > -mfpu=...'. > > > > Good idea. > > Yes, pretty rad! :-) > > > 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). > > Let's handle things one by one. Pure hard FP can be addressed in a > separate 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? > > We should not rely on some internal black-magic-that-can-change-between- > versions-or-the-phase-of-the-moon to decide what to do. Let's be explicit > about it, even if redondant. Let's just do it right. ;-) > > > I wonder if the softfp/hard case had > > not been dropped on purpose by Yann to avoid some issues on non-ARM targets. > > Well, I mostly target pure soft float, as my machines do not have an FPU (in > fact, my beagleboard has, but I have not yet had time to investigate...) > > And non-ARM should just behave. > > [--SNIP--] > > +config ARCH_SUPPORT_SOFTFP > > + bool > > + default n > > 'default n' is not needed. 'n' *is* the default. > > > [*---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). > > Yes, indeed. And this page is very interesting to read: > http://wiki.debian.org/ArmHardFloatPort/VfpComparison#Details_on_GCC_floating-point_options > > Also: I would not put it in the choice. In my opinion, 'softfp' is just > one kind of hard-float. It's an ARM-only option. Eg., smthg like: > > config/arch/arm.in.2: > config ARCH_ARM_SOFTFP > bool > prompt "Use 'softfp'" > depends on ARCH_FLOAT_HARD > > > > 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"; } > > > + > > Such contructs are hard to maintain in the long run. Please use: > if [ ...]; then > ... > fi > > Yeah, I know there are a bunch of them in the code. I leave them alone, but > as soon I need to tweak them, they get rewritten of if-then[-else]-fi. Takes > more lines, but easier to read/understand/maintain/fix. > > > Why not moving that to scripts/functions, below CT_ARCH_FLOAT_SW, > > If we go with 'softfp' as a pure ARM option (as suggested above), then the > comment is moot. > > If 'softfp' is deemed a generic option, then it should go to the generic > script, indeed. > > > 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? > > I don't know about a target that supports softfp. Either they have an FPU, > or none at all. I don't think any architecture but ARM supports softfp... s390 supports soft ftp for older hardware versions that did not have IEEE binary floating point hardware. http://gcc.gnu.org/onlinedocs/gcc/S_002f390-and-zSeries-Options.html Linux can also use software emulation if software uses the hardware floating point instructions and the processor does not support them. > > > > 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. > > Yeah. If we treat 'softfp' as a kind of hard-float (as suggested above), > then this should work, right? > > > > 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. > > Yep. > > > Apart from that, sounds good to me. > > Yes! Pretty neat, we have a working starting point to work on! Yeah! \o/ > Thank you! > > Regards, > Yann E. MORIN. > -- 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] |