Date: Thu, 16 Mar 2017 16:16:47 +0100 From: Michal Meloun <melounmichal@gmail.com> To: Sylvain Garrigues <sylvain@sylvaingarrigues.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> In-Reply-To: <E6BC9F77-F65B-4918-9E22-3BFECA268E30@sylvaingarrigues.com> 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> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <E6BC9F77-F65B-4918-9E22-3BFECA268E30@sylvaingarrigues.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16.03.2017 11:41, Sylvain Garrigues wrote: > Hi, > >> Le 10 mars 2017 à 18:51, Mark Millard <markmi at dsl-only.net> a écrit : >> >> 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.) > > Reading through this thread I understand one can definitely get into trouble with a system which has CPUTYPE=cortex-a7 in make.conf (or even some -mcpu=cortex-a7 in some CFLAGS variable there), especially if a port does FP stuff in a signal handler (because FP registers are not well preserved / restored on the kernel side). Not exactly. The problem is common for armv6, irrespective of CPUTYE or CFLAGS value. And can be observed *only* if program uses FP instructions in signal handler. > > As Michal wrote: >> Unfortunately, on armv6, the VFP part of kernel <-> userland interaction >> is broken from day 1. > > This kind of frightens me, is there any plan to fix it soon (I’d help if I could)? > > I understand Andrew's tiny patch (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff <https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff>) fixes VFP interactions during signal handling, would that fix all the "VFP part of kernel <-> userland interaction »? > > Is fixing VFP already being discussed in a Phabricator’s review or are you guys discussing a backward-compatible alternative to ABI-breaking (although we are not required to do so since we are still tier-2) elsewhere? > > Needless to say, I see strong interest in being able to just dump "CPUTYPE=<my cpu variant>" in make.conf on arm and be confident my system will be fine and fine-tuned, just like I do for all my x86/amd64 machines with such a flag. > Firstly, thanks to Andrew for perfect bug analysis. Currently, you can compile you kernel/userland/port with CPUTYPE/CFLAGS without any additional problem(s). I use this for all my ARM systems for more that last 6-months... The 'other' interfaces are gdb, porcfs, libpthtread. I work on this, but I still have not any output. Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?674facba-68cd-8ce1-887a-1ef3c51520bc>