On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore <i...@freebsd.org> wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh <i...@bsdimp.com> writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbe...@vfemail.net> > > > wrote: > > > > > > > > > > > Warner Losh <i...@bsdimp.com> 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. >
Ah, yes. We should do that. We need that for other reasons as well. It shouldn't be too hard, though I don't know where we get the AT_HWCAP from to start with. > 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. Totally agreed, even if it means breaking compatibility with the past. And as important as these issues are, they are orthogonal to armv7 :) Warner -- 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 -</dev/null > > |& fgrep -i neon > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0x4 > > #define __ARM_NEON__ 1 > > _______________________________________________ > > _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"