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

On 9/12/23 23:28, Mark Millard wrote:
> [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)
> 

Yeah, sorry, I see the problem now; looks like I didn't test it after 
one last change I ported from jhb's cheri branch:

 >      tf_size = regcache_map_entry_size (trapframe_map);

regcache_map_entry_size() is in-fact what we want, but I didn't realize 
that it doesn't do the magical translation from 0 -> register_size that 
seems to be done everywhere else.  With the below patch[0] to populate 
all of the sizes, things look sane again.

Thanks,

Kyle Evans

[0] https://people.freebsd.org/~kevans/kgdb-fix.diff

@@ -126,13 +126,13 @@ aarch64_fbsd_supply_pcb(struct regcache *regcache, 
CORE_ADDR pcb_addr) 
 

 
 
 

 
 
 

  static const struct regcache_map_entry aarch64_fbsd_trapframe_map[] = 
 
 

    { 
 
 

-    { 1, AARCH64_SP_REGNUM, 0 },
-    { 1, AARCH64_LR_REGNUM, 0 },
-    { 1, AARCH64_PC_REGNUM, 0 },
-    { 1, AARCH64_CPSR_REGNUM, 0 },
+    { 1, AARCH64_SP_REGNUM, 8 },
+    { 1, AARCH64_LR_REGNUM, 8 },
+    { 1, AARCH64_PC_REGNUM, 8 },
+    { 1, AARCH64_CPSR_REGNUM, 8 },
      { 1, REGCACHE_MAP_SKIP, 8 },       /* esr */
      { 1, REGCACHE_MAP_SKIP, 8 },       /* far */
-    { 30, AARCH64_X0_REGNUM, 0 },      /* x0 ... x29 */
+    { 30, AARCH64_X0_REGNUM, 8 },      /* x0 ... x29 */
      { 0 },
    };

@@ -141,12 +141,12 @@ static const struct regcache_map_entry 
aarch64_fbsd_trapframe_map[] =

  static const struct regcache_map_entry aarch64_fbsd13_trapframe_map[] =
    {
-    { 1, AARCH64_SP_REGNUM, 0 },
-    { 1, AARCH64_LR_REGNUM, 0 },
-    { 1, AARCH64_PC_REGNUM, 0 },
+    { 1, AARCH64_SP_REGNUM, 8 },
+    { 1, AARCH64_LR_REGNUM, 8 },
+    { 1, AARCH64_PC_REGNUM, 8 },
      { 1, AARCH64_CPSR_REGNUM, 4 },
      { 1, REGCACHE_MAP_SKIP, 4 },       /* esr */
-    { 30, AARCH64_X0_REGNUM, 0 },      /* x0 ... x29 */
+    { 30, AARCH64_X0_REGNUM, 8 },      /* x0 ... x29 */
      { 0 },
    };