When asking for the backtrace of a secondary processor in ddb, if that
backtrace reaches the secondary cpu startup code before the
switch_trampoline call, it will trust uninitialized stack data and is
likely to panic with an unaligned access at db_stack_trace_print+0x1d0.
(this was found the hard way by landry@ many years ago due to another
bug which got quickly fixed)
The following diff makes sure the secondary processor stack is correctly
set up to hint the backtrace code that it should not attempt to go
further.
Index: locore.S
===================================================================
RCS file: /OpenBSD/src/sys/arch/hppa/hppa/locore.S,v
retrieving revision 1.193
diff -u -p -r1.193 locore.S
--- locore.S 23 Oct 2014 16:57:45 -0000 1.193
+++ locore.S 2 Feb 2021 17:08:57 -0000
@@ -2970,6 +2970,9 @@ ENTRY(hw_cpu_spinup_trampoline, 0)
stw r0, HPPA_FRAME_CRP(sp)
stw r0, HPPA_FRAME_PSP(sp)
+ ldil L%TFF_LAST, t1
+ stw t1, TF_FLAGS-TRAPFRAME_SIZEOF(sp)
+
/* Provide CPU with page tables. */
ldil L%hppa_vtop, t1
ldw R%hppa_vtop(t1), t1
