Update CPU numbers for exiting and newborn threads.

[jhb]

Summary

kgdb uses td_oncpu to determine if a thread is running and should use
a pcb from stoppcbs[] rather than the thread's PCB. However, exited threads
retained td_oncpu from the last time they ran, and newborn threads had their
CPU fields cleared to zero during fork and thread creation since they are
in the set of fields zeroed when threads are setup. To fix, explicitly
update the CPU fields for exiting threads in sched_throw() to reflect the
switch out and reset the CPU fields for new threads in sched_fork_thread()
to NOCPU.

Test Plan

• Run kgdb against a core where some threads have never run after being created. One case is the IRQ1 ithread in a bhyve vm.

[kib]

sys/kern/sched_ule.c

2084 ↗

(On Diff #7279)

Should the td_oncpu and td_lastcpu fields removed from the td_zero region ?

2709 ↗

(On Diff #7279)

This still leaves a race where td_oncpu is NOCPU for still running thread, until cpu_throw() did not switched the context. Is it important ?

[jhb]

sys/kern/sched_ule.c

2084 ↗

(On Diff #7279)

Probably. I can do a followup for HEAD that would do that.

2709 ↗

(On Diff #7279)

I can't think of a good way to make this perfect. kgdb used to use TDS_RUNNING to test for this, but that was removed in r275644. I had suggested to Dmitry that he drop the TDS_RUNNING test entirely. Perhaps we could put that back. However, in thread_exit() we set TDS_INACTIVE before sched_throw() is even called, so this change has a narrower race than if we re-add the TDS_RUNNING test.

Of course, that won't fix cores from older kernels. OTOH, the way this breakage manifests is you get what should be an obviously-wrong stack trace for a thread that has never run.