[Buildroot] [PATCH 4/9] arch/arm: do not allow soft-float for armv8a

[Yann E. MORIN <yann.morin.1998@free.fr>]

Arnout, All,

On 2017-11-25 18:10 +0100, Arnout Vandecappelle spake thusly:
> On 24-11-17 23:08, Thomas Petazzoni wrote:
> > 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?
> 
>  gcc aarch64

It's not about aarch64, it's about aarch32, i.e. an armv8a core running
in 32-bit mode.

> doesn't have a float-abi option, so no it's not possible to build
> with soft-float. So the depends on BR2_ARM_EABI is certainly needed.
> 
>  That said, I don't think it makes a lot of sense to add extra 'depends on'
> lines just to avoid that the user would select an option that probably doesn't
> make sense. We already make sure that the default is appropriate. Let's not make
> our life more difficult.

It's not about making *our* lives more dificult or easier. It's about
making the user's lives easier.

If there is a prompt that offers an option, but that has no impact on
the resulting output, then that prompt should not exist. Otherwise, it
is very confusing.

Regards,
Yann E. MORIN.

>  So I'd say: reject this patch.
> 
>  Regards,
>  Arnout
> 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'