From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 4/9] arch/arm: do not allow soft-float for armv8a
Date: Fri, 24 Nov 2017 23:08:57 +0100 [thread overview]
Message-ID: <20171124230857.0b6e1648@windsurf.lan> (raw)
In-Reply-To: <20170904172137.GB5223@scaer>
Hello,
On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote:
> Thomas, All,
>
> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
> > armv8a has made VFPv4 and NEON mandatory, so there is no point in
> > allowing software floating point, even in 32-bit mode.
>
> In fact, even though I'm pretty sure that OK in 64-bit, we might still
> have a reason to do soft-float in 32-bit mode, if only for legacy
> binary-only applications that were built as soft-float way back in the
> (not so) good old days...
>
> In which case, we should instead depend on !BR2_ARCH_IS_64.
>
> Thoughts?
I'm hesitating on this one. I believe the use-case you mention makes
sense, however I believe that it can still be supported with your
proposed patch.
Indeed, even if you want to run a binary-only soft-float application,
it doesn't prevent the rest of your system from using VFP, as long as
you use EABI (and not EABIhf).
The whole reason why EABI passes floating-point arguments into integer
registers is precisely to allow compatibility between soft-float code
and hard-float code. Thanks to that, a soft-float function can call a
hard-float function, and vice-versa.
Therefore, even if you have a binary-only soft-float application, there
is really no reason to build the entire system soft-float.
So, I think your original patch is OK as-is. However, I still see one
inconsistent thing: if we disallow soft-float because ARMv8-A mandates
VFPv4, why would we allow soft-float for ARMv7-A cores that have a
VFP ? To be consistent, we should also disallow soft-float.
Another way to think about this is: is it possible to build an AArch64
soft-float system? do we want to allow the user to select what is
*possible* or what makes sense?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-11-24 22:08 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-03 9:22 [Buildroot] [PATCH 0/5 v2] arch: not all have support in the internal backend Yann E. MORIN
2017-09-03 9:22 ` [Buildroot] [PATCH 1/5 v2] arch: add option to disable internal toolchain backend Yann E. MORIN
2017-09-03 9:22 ` [Buildroot] [PATCH 2/5 v2] arch/csky: internal backend not suitable Yann E. MORIN
2017-09-03 9:22 ` [Buildroot] [PATCH 3/5 v2] arch/mips: internal backend not suitable for some cores Yann E. MORIN
2017-09-03 9:22 ` [Buildroot] [PATCH 4/5 v2] arch/bfin: " Yann E. MORIN
2017-09-03 9:22 ` [Buildroot] [PATCH 5/5 v2] arc/bfin: remove 60x cores Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 0/8] arch: some require a minimal gcc version Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 1/8] arch: introduce minimal required " Yann E. MORIN
2017-10-07 9:59 ` Romain Naour
2017-10-07 10:26 ` Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 2/8] package/gcc: hide versions too old for the current arch Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 3/8] toolchain/external-custom: " Yann E. MORIN
2017-10-07 9:27 ` Romain Naour
2017-10-07 12:27 ` Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 4/8] toolchain/external: " Yann E. MORIN
2017-10-07 9:57 ` Romain Naour
2017-10-07 12:15 ` Yann E. MORIN
2017-10-07 19:55 ` Romain Naour
2017-09-03 9:44 ` [Buildroot] [PATCH 5/8] arch/bfin: needs gcc >= 6 Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 6/8] arch/mips: some variants need different gcc versions Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 7/8] arch/arm: " Yann E. MORIN
2017-09-03 9:44 ` [Buildroot] [PATCH 8/8] package/gcc: slight cleanup and reorg in remaining arch depends Yann E. MORIN
2017-09-03 9:53 ` [Buildroot] [PATCH 0/3] arch: fix MIPS NaN and floating-point handling Yann E. MORIN
2017-09-03 9:53 ` [Buildroot] [PATCH 1/3] arch/mips: inverse the NaN logic Yann E. MORIN
2017-10-07 10:18 ` Romain Naour
2017-10-07 12:22 ` Yann E. MORIN
2017-10-07 18:43 ` Romain Naour
2017-09-03 9:53 ` [Buildroot] [PATCH 2/3] arch/mips: inverse the mfpxx logic Yann E. MORIN
2017-09-03 9:53 ` [Buildroot] [PATCH 3/3] toolchain/buildroot: glibc requires header >= 4.5 with NaN-2008 Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [pull request] arch/arm: add some new armv8a cores Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 1/9] arch/arm: re-order cores choice Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 2/9] arch/arm: simplify hiding non 64-bit cores Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 3/9] arch/arm: armv8 is really armv8a Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 4/9] arch/arm: do not allow soft-float for armv8a Yann E. MORIN
2017-09-04 17:21 ` Yann E. MORIN
2017-11-24 22:08 ` Thomas Petazzoni [this message]
2017-11-25 17:10 ` Arnout Vandecappelle
2017-11-26 11:12 ` Yann E. MORIN
2017-11-26 11:18 ` Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 5/9] arch/arm: add cortex-A32 Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 6/9] arch/arm: add some armv8a cortex variants Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 7/9] arch/arm: add some non-cortex armv8a cores Yann E. MORIN
2017-09-03 14:04 ` Thomas Petazzoni
2017-09-03 15:16 ` Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 8/9] arch/arm: add armv8.1a cores Yann E. MORIN
2017-09-03 13:17 ` [Buildroot] [PATCH 9/9] [DON'T COMMIT] tests for all new arm cores Yann E. MORIN
2017-09-03 13:24 ` [Buildroot] [pull request] arch/arm: add some new armv8a cores Yann E. MORIN
2017-11-24 22:32 ` Thomas Petazzoni
2017-11-24 21:58 ` [Buildroot] [PATCH 0/3] arch: fix MIPS NaN and floating-point handling Thomas Petazzoni
2017-11-24 21:23 ` [Buildroot] [PATCH 0/8] arch: some require a minimal gcc version Thomas Petazzoni
2017-10-02 19:47 ` [Buildroot] [PATCH 0/5 v2] arch: not all have support in the internal backend Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171124230857.0b6e1648@windsurf.lan \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.