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] |
Michael, All, On Wednesday 19 October 2011 04:29:20 Michael Hope wrote: > # HG changeset patch > # User Michael Hope <michael.hope@linaro.org> > # Date 1318991252 -46800 > # Node ID a31d097e28cd73d07a5484129929a500b4d58efa > # Parent a32156bd31c0d395e8d346431b123a7d2caa14cd > scripts: add softfp support > > ARM compilers can be built for soft float (software only, floats in > core registers), hard float (uses floating point instructions, floats > in FPU registers), or the half-way house softfp (uses floating point > instructions, floats in core registers). Feature definitely a nice addition, but too close to the release to add it now (which reminds me I should document the release plan on the website...). FYI, it's a release every three months, with about a 15-day slack before, used to stabilise the stuff. Next release is due by October the 31st, so we just entered the 15-day delay... I was thinking about cutting the release branch ahead of time, but handling both the relase and the devel at the same time is a bit complicated in my head, and does colide a bit on the schedule... I'd like to try, but this release is special: it also colides with the Prague events. Probably I'll do it for the next release (Feb`12)... > Add support for softfp cross compilers to the GCC and GLIBC > configuration. Needed for Ubuntu and other distros that are softfp. What about uClibc? How will it cope with softfp? > Signed-off-by: Michael Hope <michael.hope@linaro.org> > > diff -r a32156bd31c0 -r a31d097e28cd config/target.in > --- a/config/target.in Sun Oct 16 17:51:42 2011 +0200 > +++ b/config/target.in Wed Oct 19 15:27:32 2011 +1300 > @@ -271,6 +271,22 @@ > 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 I'm a bit reluctant at adding an architecture-specific option to this generic file. Currently, all arch options are in the related arch file. However, I agreee that there is no easy way to nicely handle that with the current infrastructure... :-/ *But* I recall a similar approach a few months back... It seemed that ARM is not the only architecture that support softfp. Seems PPC also uses it. So: > + bool > + prompt "softfp" > + depends on ARCH_arm - this arch-specific "depends on" should go away - and either we keep the option un-protected, or we hide it behind ARCH_SUPPORT_SOFTFP (or the like) which is set by archs that support it. > + help > + Emit hardware floating point opcodes but use the software > + floating point calling convention. > + > + Architectures such as ARM use different registers for passing > + floating point values depending on if they're in software mode > + or hardware mode. softfp emits FPU instructions but uses the > + software FP calling convention allowing softfp code to > + interoperate with legacy software only code. > + > + If in doubt, use 'software' or 'hardware' mode instead. > + > endchoice > > config TARGET_CFLAGS > diff -r a32156bd31c0 -r a31d097e28cd scripts/build/libc/glibc-eglibc.sh-common > --- a/scripts/build/libc/glibc-eglibc.sh-common Sun Oct 16 17:51:42 2011 +0200 > +++ b/scripts/build/libc/glibc-eglibc.sh-common Wed Oct 19 15:27:32 2011 +1300 > @@ -132,9 +132,10 @@ > *) 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,) extra_config+=("--without-fp");; > + ,,y) extra_config+=("--with-fp");; > esac Argh!... This is starting to be unreadable... :-/ config ARCH_FLOAT string default "hard" if ARCH_FLOAT_HW default "soft" if ARCH_FLOAT_SW default "softfp" if ARCH_FLOAT_SOFTFP Then: case "${CT_ARCH_FLOAT}" in hard) ...;; soft) ...;; softfp) ...;; esac I'll do it. > if [ "${CT_LIBC_DISABLE_VERSIONING}" = "y" ]; then > diff -r a32156bd31c0 -r a31d097e28cd scripts/functions > --- a/scripts/functions Sun Oct 16 17:51:42 2011 +0200 > +++ b/scripts/functions Wed Oct 19 15:27:32 2011 +1300 > @@ -984,6 +984,7 @@ > [ "${CT_ARCH_TUNE}" ] && { CT_ARCH_TUNE_CFLAG="-mtune=${CT_ARCH_TUNE}"; CT_ARCH_WITH_TUNE="--with-tune=${CT_ARCH_TUNE}"; } > [ "${CT_ARCH_FPU}" ] && { CT_ARCH_FPU_CFLAG="-mfpu=${CT_ARCH_FPU}"; CT_ARCH_WITH_FPU="--with-fpu=${CT_ARCH_FPU}"; } > [ "${CT_ARCH_FLOAT_SW}" ] && { CT_ARCH_FLOAT_CFLAG="-msoft-float"; CT_ARCH_WITH_FLOAT="--with-float=soft"; } > + [ "${CT_ARCH_FLOAT_SOFTFP}" ] && { CT_ARCH_FLOAT_CFLAG="-mfloat-abi=softfp"; CT_ARCH_WITH_FLOAT="--with-float=softfp"; } And the last time this came up, it was pointed that CT_ARCH_FLOAT_HW did force neither -hard-float not --with-float=hard I'll look at it... > # Build the default kernel tuple part > CT_TARGET_KERNEL="${CT_KERNEL}" Can we sit on this for now, and revisit after the release? Thank you! Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- 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] |