From owner-freebsd-arm@freebsd.org Fri Mar 10 18:51:07 2017 Return-Path: Delivered-To: freebsd-arm@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 84E81D06042 for ; Fri, 10 Mar 2017 18:51:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 46B722FC for ; Fri, 10 Mar 2017 18:51:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9116 invoked from network); 10 Mar 2017 17:51:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Mar 2017 17:51:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 10 Mar 2017 12:51:05 -0500 (EST) Received: (qmail 23927 invoked from network); 10 Mar 2017 17:51:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Mar 2017 17:51:05 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 85F62EC884C; Fri, 10 Mar 2017 09:51:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87wpbxw3yd.fsf@news-spur.riddles.org.uk> Date: Fri, 10 Mar 2017 09:51:03 -0800 Cc: Andrew Gierth , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> To: Warner Losh X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:51:07 -0000 On 2017-Mar-10, at 8:10 AM, Andrew Gierth wrote: >=20 >>>>>> "Warner" =3D=3D Warner Losh 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