Is CPUTYPE=cortex-A7 supposed to work?
Sylvain Garrigues
sylvain at sylvaingarrigues.com
Thu Mar 16 10:41:18 UTC 2017
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).
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.
Have all a good day,
Sylvain
More information about the freebsd-arm
mailing list