Is CPUTYPE=cortex-A7 supposed to work?

[Michal Meloun]

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