From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22421 invoked by alias); 19 Oct 2011 21:02:36 -0000 Received: (qmail 22407 invoked by uid 22791); 19 Oct 2011 21:02:33 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp07.smtpout.orange.fr (HELO smtp.smtpout.orange.fr) (80.12.242.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 21:02:15 +0000 Received: from treguer.localnet ([90.32.124.9]) by mwinf5d42 with ME id ml2C1h0020CGihW03l2Ckq; Wed, 19 Oct 2011 23:02:13 +0200 X-ME-engine: default From: "Yann E. MORIN" To: Michael Hope Subject: Re: [PATCH] scripts: add softfp support Date: Wed, 19 Oct 2011 21:02:00 -0000 User-Agent: KMail/1.13.5 (Linux/3.0.6-treguer; KDE/4.4.5; x86_64; ; ) Cc: crossgcc@sourceware.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110192302.12549.yann.morin.1998@anciens.enib.fr> Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00049.txt.bz2 Michael, All, On Wednesday 19 October 2011 04:29:20 Michael Hope wrote: > # HG changeset patch > # User Michael Hope > # 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 > > 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