Page MenuHomeFreeBSD

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

Authored by jhb on Sep 9 2017, 2:35 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 3:27 AM
Unknown Object (File)
Aug 28 2023, 5:57 AM
Unknown Object (File)
Jun 28 2023, 12:57 AM
Unknown Object (File)
Mar 21 2023, 11:38 AM
Unknown Object (File)
Mar 3 2023, 4:11 PM
Unknown Object (File)
Nov 26 2022, 9:46 PM
Subscribers

Details

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.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 11552
Build 11905: arc lint + arc unit

Event Timeline

stevek added a reviewer: stevek.

Looks good.

This revision is now accepted and ready to land.Sep 9 2017, 3:04 PM

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

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

sys/arm/arm/machdep.c
419–421

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).

sys/arm/arm/machdep.c
419–421

Is there a way to assert the thread is stopped?

sys/arm/arm/machdep.c
419–421

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.)

  • Assert threads are suspended for get/set_vfpcontext.
This revision now requires review to proceed.Sep 14 2017, 12:10 AM
This revision was automatically updated to reflect the committed changes.