sys: Add cpu_update_pcb hook

[jhb]

Summary

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.

[jhb]

Another ppc update

[jhb]

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

[kib]

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.

[jhb]

In D44910#1024125, @kib wrote:

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.

Where would you want that comment to go? Next to its prototype in <sys/proc.h>?

[kib]

In D44910#1026299, @jhb wrote:

In D44910#1024125, @kib wrote:

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.

Where would you want that comment to go? Next to its prototype in <sys/proc.h>?

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

[jhb]

Add comment describing the new hook

[jrtc27]

sys/amd64/amd64/vm_machdep.c

690

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?