FCP-100: armv7 plan

[Warner Losh]

On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore <ian at freebsd.org> wrote:

> On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote:
> > Warner Losh <imp at bsdimp.com> writes:
> >
> > >
> > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbeich at vfemail.net>
> > > wrote:
> > >
> > > >
> > > > Warner Losh <imp at 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
> > _______________________________________________
>
>