Date: Fri, 10 Mar 2017 09:51:03 -0800 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <8737ely05c.fsf@news-spur.riddles.org.uk> <CANCZdfpftVHaPahTOP0vxB-FR%2BKtpqY9JMJr=F2DGifD0fhKMQ@mail.gmail.com> <87wpbxw3yd.fsf@news-spur.riddles.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-10, at 8:10 AM, Andrew Gierth <andrew at = tao11.riddles.org.uk> wrote: >=20 >>>>>> "Warner" =3D=3D Warner Losh <imp@bsdimp.com> writes: >=20 > Warner> I've not had good luck getting it to work. (cortex-a7 is the > Warner> proper type name, btw). It kinda works, but ports are kinda > Warner> wonky. >=20 >>> Well, I can now report that with a local fix for #217611 in place >>> and everything recompiled for cortex-a7, I'm not seeing any >>> wonkiness at all even with a lot of ports in use. >=20 > Warner> Awesome. What's the local fix? Is it in FreeBSD yet? >=20 > No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla > report: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217611 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180669&action=3Ddi= ff >=20 > My fix requires breaking the ABI, since the definition of mcontext_t > simply does not have enough space to store all the registers, so I'm > assuming it won't go into stable/11 (though that really needs _some_ > kind of fix, since the bug can be demonstrated with ordinary > floating-point code and no compile options). To be explicit: armv6 VFP use can have the issue too, depending on what signal handlers do. Also, as Andrew wrote in comment #2: > The use of -mcpu=3Dcortex-a7 or similar option just broadens the = problem > to include every program that might have vector operations in a signal > handler (which includes all programs with signal handlers if linked > with libthr) as well as in the main program. Going in another direction: There is a less common context with the problem that need not involve floating point code. But it takes a compiler option to enable Integer NEON and armv6 does not have NEON so the contexts are more limited. (I'm ignoring compiler directives internal to source code or assembler use.)=20 http://lists.llvm.org/pipermail/llvm-dev/2016-March/097613.html (2016-Mar-25) indicates that llvm/clang was intended to eventually have: > Examples: >=20 > Works today: > -mfpu=3Dsoft -> Int (ALU), FP (LIB), no VFP/NEON instructions > -mfpu=3Dsoftfp -> Int (ALU), FP (LIB), VFP/NEON instructions allowed > -mfpu=3Dvfp -> Int (ALU), FP (VFP) > -mfpu=3Dneon -> Int (NEON), FP (NEON) >=20 > Change proposed: > -mfpmath=3Dneon -mfpu=3Dvfp -> Int (ALU), FP (NEON) > -mfpmath=3Dvfp -mfpu=3Dneon -> Int (NEON), FP (VFP) So if -mfpu=3DNEON has been specified but there are no floating point data types in use at all the extra registers can still be in use for just integer data. Such code could have problems with signals not preserving those register values. So not only is armhf not implemented correctly in stable/11, release/11.0.1, and head, effectively FreeBSD does not support Integer NEON use when no floating point data types are in use. (Or it constrains what signal handlers are allowed to do.) So overall: If the ABI stays as it is for 11 (or 12), floating point in general (VFP with or without NEON) and Integer NEON can be broken when signals are involved that allow the code to keep going instead of exiting the process. (This means all NEON use is subject to the issue.) Or at least FreeBSD constrains what signal handlers are allowed to do but for some compiler options (such as -mcpu=3Dcortex-a7) FreeBSD itself currently violates those constraints. > It needs attention from someone with more kernel/arm experience than I > have to see whether I've missed something obvious (or subtle).=20 >=20 > (Maybe I should have filed it under "kern" rather than "arm"?) >=20 > --=20 > Andrew. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79EBD44B-2C2D-4394-A90C-DF494A049F20>