This MD function is invoked before dumping register set notes when
writing out a core dump to ensure that the PCB for a given thread is
up to date. This provides a centralized place to update the PCB with
values of the current thread for each arch rather than doing this work
in each register set's get method.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 61483 Build 58367: arc lint + arc unit
Event Timeline
Comment Actions
Right now the TLS register sets I added for arm64 and arm are missing the update in their get methods. It seems nicer to handle this in one place vs in each get method?
However, in theory this function should be something we use e.g. when copying pcb's for fork or creating threads, and in theory it should perhaps deal with fetching updated FPU registers as well. The latter tends to happen in fill_fpregs directly instead. The i386 change in particular is with an eye towards this possible longer term goal since pcb_gs isn't used in any get methods currently.
Related is that it would be nice to move more MD register sets (XSAVE, the PPC ones) over to using the regset stuff instead of elfNN_dump_thread. I know @andrew had an older patch set at some point to handle XSAVE. Would be nice to do XSAVE in a single place (sys/x86/x86/x86_ptrace.c or some such).
Comment Actions
Could the purpose of the new cpu method expressed as "move CPU state to PCB/thread save location in preparation for ..."? I think a comment like that would be due.
Comment Actions
Might be, near the method definition for one of the Tier-1 arch is enough.
Otherwise it would be a whole project to document all cpu_* methods in the header (but not a useless, just lot of typing and probably code reading).
| sys/amd64/amd64/vm_machdep.c | ||
|---|---|---|
| 680 | Is there ever a situation where you'd want to do something in this function on an architecture if this wasn't true? If not, would it make sense to push this to the few callers instead (and KASSERT here and/or implicitly use curthread?), or at least using an early return in every function? | |
| sys/kern/imgact_elf.c | ||
|---|---|---|
| 2424 | Is it td or target_td? | |
| sys/amd64/amd64/vm_machdep.c | ||
|---|---|---|
| 680 | I believe yes, see my comment for kern/imgact_elf.c. | |
| sys/kern/imgact_elf.c | ||
|---|---|---|
| 2424 | Oh, yes, this should be target_td | |
| sys/amd64/amd64/vm_machdep.c | ||
|---|---|---|
| 680 | On our current architectures I think it is always true that you can only have stale pcb values for the current thread. It might be ok to assume curthread for this API. One non-obvious thing for fork/cpu_copy_thread btw is that they can be called with the "old" thread being thread0 instead of curthread when creating new kprocs/kthreads. | |