riscv: decode syscall in ddb backtrace

[mhorne]

Summary

De-dup decode_syscall() and move it to an MI place.

Test Plan

# sysctl debug.kdb.enter=1
debug.kdKDB: enter: sysctl debug.kdb.enter
[ thread pid 1062 tid 100202 ]
Stopped at      kdb_sysctl_enter+0x84:  sd      zero,0(s1)
db> bt
Tracing pid 1062 tid 100202 td 0xffffffc2085805a0
kdb_sysctl_enter() at kdb_sysctl_enter+0x82
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xaa
sysctl_root() at sysctl_root+0x1ea
userland_sysctl() at userland_sysctl+0x124
sys___sysctl() at sys___sysctl+0x56
do_trap_user() at do_trap_user+0x200
cpu_exception_handler_user() at cpu_exception_handler_user+0x72
--- syscall (202, FreeBSD ELF64, sys___sysctl)
db>

[jrtc27]

Didn't know we even had this, normally not very useful as the function (or a related user/kern_foo) appears in the stack trace but I can see cases where it's not totally clear or unambiguous. Please commit the MI move separately from the riscv change though.

sys/ddb/db_sym.c

501

Useful follow-up might be to hoist the , sv_name out of the if, that's available regardless of whether DDB found the symbol name.

There's also syscallname in subr_trap.c that gets it from the generated tables rather than querying symbol info (so won't have the sys_/freebsd32_/etc prefix). Maybe more useful given the symbol is typically in the backtrace, and this is really trying to print the trapframe info; only issue with it is sv_syscallnames isn't currently set for Linux ABIs but we do have those arrays these days (maybe they weren't there in the past?).

[jhb]

sys/ddb/db_sym.c

501

Hmmm, I agree that I think printing out the syscall name is closer to the intent. It probably uses the function name due to not always having the names available though. I'd rather we just include sv_syscallnames always?

However, that's also something to fix later as a followup. Hoisting the existing code to MI is fine for now.

[mhorne]

sys/ddb/db_sym.c

501

Thanks for the suggestion, I will do this as a follow-up.