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

[Alexander Richardson]

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?

Alex