arm64: extend ESR/SPSR registers to 64b

[zachary.leaf_arm.com]

Summary

For the Exception Syndrome Register, ESR_ELx, the upper 32b were
previously unused, but now may contain additional exception info as of
Armv8.7 (FEAT_LS64).

Extend ESR from u32->u64 in exception handling code to support this. In
addition, also extend Saved Program Status Register SPSR_ELx in the same
way to allow for future extensions.

Sponsored by: Arm Ltd

[andrew]

sys/arm64/include/reg.h

43

One thing I'm not sure about is if this will break the ABI of existing programs that use struct reg. As we are using padding from the end of the struct the data may be non-zero when passed back to the kernel from userspace.

[jhb]

sys/arm64/include/reg.h

43

Humm, I think spsr is a read-only register for ptrace()?

Oh, hmm, it is not.

frame->tf_spsr &= ~PSR_SETTABLE_64;
frame->tf_spsr |= regs->spsr & PSR_SETTABLE_64;

Were we always careful to clear the padding? Hmm, no, we only started clearing the regs structure up in sys_ptrace() back in 2018 (commit 352aaa51225671cce8ea44347e6f5a1e5f7daaf8 by @markj).

That said, GDB at least always does a read-modify-write sequence anytime it calls PT_SETREGS where it does a PT_GETREGS first, applies specific register modifications, then does a PT_SETREGS, so it should be ok so long as I only make it start treating the register as wider in sufficiently recent versions via a __FreeBSD_version check at compile-time. I don't know what LLDB does, but I think read-modify-write is the only really sane way to use PT_SETREGS.

[andrew]

My plan is to commit this stack with D35378 and a separate __FreeBSD_version bump

sys/arm64/include/reg.h

43

I think this one is ok, as long as PSR_SETTABLE_64 doesn't include the upper 32 bits of reg->spsr. The issue is if the copy is stored in struct reg the compiler is free to modify the trailing padding.

From memory, lldb will store it in a buffer large enough to hold struct reg and knows the offset of each field so should only change the field it needs to change.