Only mess with VFP state on the CPU for curthread for get/set_vfpcontext.

[jhb]

Summary

Future changes will use these functions to fetch and store VFP state for
threads other than curthread.

Test Plan

This is part of a patch series for using VFP with gdb on armv7.

[stevek]

Looks good.

[andrew]

I have a slight concern about a non-current thread being run at the same time as this leading to a potential data race.

sys/arm/arm/machdep.c

419–421 ↗

(On Diff #32848)

Should the critical section be reduced? What about if td was scheduled during this memcpy & updated its vfp registers?

[jhb]

sys/arm/arm/machdep.c

419–421 ↗

(On Diff #32848)

If it is curthread then all it will do if it gets preempted and rescheduled is then execute this memcpy(). If it isn't curthread, the thread is stopped (either due to a ptrace() stop or because we are single-threaded to write out a core dump).

[andrew]

sys/arm/arm/machdep.c

419–421 ↗

(On Diff #32848)

Is there a way to assert the thread is stopped?

[jhb]

sys/arm/arm/machdep.c

419–421 ↗

(On Diff #32848)

Possibly? We don't do this on any other architecture for fill_*regs though, it's just part of the API contract. (This is equivalent in nature to the patch I committed for arm64 to fix panics for PT_GETFPREGS a few weeks ago.)

[jhb]

• Assert threads are suspended for get/set_vfpcontext.