Re: aarch64 devel/gdb for kgdb use on main [so: 15] (and, likely, 14.0-????): dump core.txt.?'s kgdb backtraces are messed up

[Trying to send to freebsd-ports accurately this time.]

On Sep 12, 2023, at 21:23, Mark Millard <marklmi@yahoo.com> wrote:

[I've cc'd the last 2 devel/gdb authors of kgdb-related material.]

kgdb 13.1_4 is an improvement over 13.1_3 for aarch64 but is still
broken. 13.1_3 example:

0x0000000000000000 in ?? ()
(kgdb) #0  0x0000000000000000 in ?? ()
#1  <unavailable> in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further
(kgdb) 

13.1_4 example:

get_curthread () at /usr/src/sys/arm64/include/pcpu.h:77
77 __asm __volatile("ldr %0, [x18]" : "=&r"(td));
(kgdb) #0 get_curthread () at /usr/src/sys/arm64/include/pcpu.h:77
#1 doadump (textdump=0, textdump@entry=1576585744)
at /usr/src/sys/kern/kern_shutdown.c:405
#2 0xffff0000000ec18c in db_dump (dummy=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>)
at /usr/src/sys/ddb/db_command.c:591
#3 0xffff0000000ebf88 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=true)
at /usr/src/sys/ddb/db_command.c:504
#4 0xffff0000000ebc80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:551
#5 0xffff0000000ef440 in db_trap (type=<optimized out>, code=<optimized out>)
at /usr/src/sys/ddb/db_main.c:268
#6 0xffff0000004b4860 in kdb_trap (type=60, code=0, tf=<optimized out>)
at /usr/src/sys/kern/subr_kdb.c:790
#7 <signal handler called>
#8 <signal handler called>
#9 <signal handler called>
#10 <signal handler called>
#11 <signal handler called>
#12 <signal handler called>
#13 <signal handler called>
#14 <signal handler called>
#15 <signal handler called>
#16 <signal handler called>
#17 <signal handler called>
#18 <signal handler called>
#19 <signal handler called>
#20 <signal handler called>
#21 <signal handler called>
#22 <signal handler called>
#23 <signal handler called>
Backtrace stopped: Cannot access memory at address 0x10
(kgdb) 

(Same kernel [from a snapshot], different worlds involved.)

The backtraces are from the panic reporting at:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273081

(for a kyua test). I'll note that prior to the kgdb
backtrace is a non-kgdb backtrace, such as:

panic: vm_fault failed: 0xffff0000006813b4 error 1
cpuid = 3
time = 1694485392
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x19c
panic() at panic+0x44
data_abort() at data_abort+0x35c
handle_el1h_sync() at handle_el1h_sync+0x14
--- exception, esr 0x96000004
dump_sa() at dump_sa+0x1c
dump_iface() at dump_iface+0x2bc
dump_cb() at dump_cb+0x18
if_foreach_sleep() at if_foreach_sleep+0x254
rtnl_handle_getlink() at rtnl_handle_getlink+0xec
rtnl_handle_message() at rtnl_handle_message+0x19c
nl_taskqueue_handler() at nl_taskqueue_handler+0x5dc
taskqueue_run_locked() at taskqueue_run_locked+0x17c
taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14

Such is more useful at this point.

===
Mark Millard
marklmi at yahoo.com