Future changes will use these functions to fetch and store VFP state for
threads other than curthread.
Details
Details
This is part of a patch series for using VFP with gdb on armv7.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 11452 Build 11808: arc lint + arc unit
Event Timeline
Comment Actions
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.) | |