From owner-freebsd-toolchain@freebsd.org Sat Sep 9 20:34:13 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0690E0890E for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91E8B7C998 for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 44f804e6-959e-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 44f804e6-959e-11e7-950d-03a3531dacf2; Sat, 09 Sep 2017 20:34:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v89KYArr004518; Sat, 9 Sep 2017 14:34:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504989250.32063.66.camel@freebsd.org> Subject: Re: FCP-100: armv7 plan From: Ian Lepore To: Jan Beich , Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Date: Sat, 09 Sep 2017 14:34:10 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:34:13 -0000 On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > wrote: > > > > > > > > Warner Losh writes: > > > > > > > > > > > Greetings, > > > > > > > > This will serve as 'Last Call' for any objections to the plan > > > > to create > > > an > > > > > > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > [...] > > > > > > Some ports want NEON support but FCP-0100 is vague about FreeBSD- > > > specific > > > differences between armv6 and armv7. Clang appears to enable NEON > > > for all > > > *-gnueabi* targets but I have no clue about GCC. Apparently, > > > Android and > > > Debian don't assume NEON on armv7. > > > > > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > > > > Yes. We are vague about it on purpose. Just like we're vague about > > MMX, > > MMX2, etc on x86 because different processors can/want use > > different > > things. > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? > > > > > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a > > CPU. > FreeBSD doesn't support detecting NEON at runtime unlike Linux. We should fix that.  In fact, we should probably fix it in exactly the way linux does it (does it today, I think it's their 3rd scheme so far), using getauxval() and elf AT_HWCAP. Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure what to do about getauxval().  To be maximally linux-compatible (which would be good for ports) we'd put getauxval() in libc and make it work just like the linux one.  That's a bit at odds with the support we have now, which is procstat_getauxv() in libprocstat.  It's not very compatible with how linux getauxval() works, so using just that might lead to a lot of patches in ports. -- Ian > Do you > mean at compile time? If so then the following probably needs to > change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - |& fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > _______________________________________________