From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Sun, 26 Nov 2017 12:12:57 +0100 Subject: [Buildroot] [PATCH 4/9] arch/arm: do not allow soft-float for armv8a In-Reply-To: <5508245a-3f6a-80b9-a7ad-b3b6bc5d5f9e@mind.be> References: <20170904172137.GB5223@scaer> <20171124230857.0b6e1648@windsurf.lan> <5508245a-3f6a-80b9-a7ad-b3b6bc5d5f9e@mind.be> Message-ID: <20171126111257.GA3101@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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. | '------------------------------^-------^------------------^--------------------'