git: 953a7d7c61f3 - main - Arch64: Clear VFP state on execve()

[John Baldwin]

On 3/10/21 9:37 AM, Alexander Richardson wrote:
> On Wed, 10 Mar 2021 at 17:29, John Baldwin <jhb at freebsd.org> wrote:
>>
>> On 3/10/21 4:45 AM, Alex Richardson wrote:
>>> The branch main has been updated by arichardson:
>>>
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=953a7d7c61f3b2f5351dfe668510ec782ae282e8
>>>
>>> commit 953a7d7c61f3b2f5351dfe668510ec782ae282e8
>>> Author:     Alex Richardson <arichardson at FreeBSD.org>
>>> AuthorDate: 2021-03-09 19:11:40 +0000
>>> Commit:     Alex Richardson <arichardson at FreeBSD.org>
>>> CommitDate: 2021-03-10 12:44:42 +0000
>>>
>>>       Arch64: Clear VFP state on execve()
>>>
>>>       I noticed that many of the math-related tests were failing on AArch64.
>>>       After a lot of debugging, I noticed that the floating point exception flags
>>>       were not being reset when starting a new process. This change resets the
>>>       VFP inside exec_setregs() to ensure no VFP register state is leaked from
>>>       parent processes to children.
>>>
>>>       This commit also moves the clearing of fpcr that was added in 65618fdda0f27
>>>       from fork() to execve() since that makes more sense: fork() can retain
>>>       current register values, but execve() should result in a well-defined
>>>       clean state.
>>>
>>>       Reviewed By:    andrew
>>>       MFC after:      1 week
>>>       Differential Revision: https://reviews.freebsd.org/D29060
>>
>> FYI, cpu_thread_copy() should copy the creating thread's state to the new thread,
>> not reset it.  POSIX actually says that new threads inherit the "floating point
>> environment" from the creating thread for pthread_create().  I have a patch I'm
>> testing to fix thix for x86.
>>
> 
> I believe sv_setregs is only called for execve() not for new threads?
> cpu_copy_thread() is not affected by this patch and I see it does a
> bcopy(td0->td_pcb, td->td_pcb, sizeof(struct pcb)); so should be fine?

Ah, I thought you touched cpu_copy_thread() as well.  I do think cpu_copy_thread()
resets some pcb flags which might be the thing to fix (it's what I have to fix
for x86 which was copying the state, but then clearing the INITDONE flags such
that the copied state was always overwritten by the trap on first use)

-- 
John Baldwin