I'm coming up to speed in Nuttx over the past few months, and I've run
into an issue where gdb can't show the call stack for a thread in
version 12.6.0, but can in version 12.5.1 (and can't show threads in
version 12.8.0):
I followed the instructions at
https://nuttx.apache.org/docs/12.6.0/guides/qemugdb.html to build/debug
Nuttx after checking out release/12.6 and running it under qemu:
peter@legion:~/git/nuttx/nuttx$ qemu-system-arm -M lm3s6965evb -device
loader,file=nuttx -serialmon:stdio -nographic -s
Timer with period zero, disabling
ABCDF
telnetd [4:100]
NuttShell (NSH) NuttX-12.5.1
nsh> uname -a
NuttX 12.6.0 7a865b2479 Jan 23 2025 16:07:15 arm lm3s6965-ek
nsh>
In another shell I attached to qemu via gdb and tried to dump the
nsh_main call stack(which failed) :
peter@legion:~/git/nuttx/nuttx$ gdb-multiarch nuttx -ex "source tools/gdb/__init__.py"
-ex"target remote 127.0.0.1:1234"
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
...
Remote debugging using 127.0.0.1:1234
0x0000a8f6 in up_idle () at chip/common/tiva_idle.c:62
62 }
(gdb) i thread
Id Thread Info
Frame
*0 Thread 0x20001688 (Name: Idle_Task, State: Running, Priority: 0,
Stack: 1008) 0xa8f6 up_idle() at chip/common/tiva_idle.c:62
1 Thread 0x200052f8 (Name: hpwork, State: Waiting,Semaphore, Priority:
224, Stack: 1984) 0xab1a up_switch_context() at
common/arm_switchcontext.c:95
2 Thread 0x20005bc0 (Name: nsh_main, State: Waiting,Semaphore, Priority:
100, Stack: 2008) 0xab1a up_switch_context() at
common/arm_switchcontext.c:95
3 Thread 0x20006a90 (Name: NTP_daemon, State: Waiting,Signal, Priority:
100, Stack: 1960) 0xab1a up_switch_context() at
common/arm_switchcontext.c:95
4 Thread 0x200088b8 (Name: telnetd, State: Waiting,Semaphore, Priority:
100, Stack: 2016) 0xab1a up_switch_context() at
common/arm_switchcontext.c:95
(gdb) thread 2
(gdb) where
#0 up_switch_context (tcb=0x20001688 <g_idletcb>, rtcb=0x20005bc0)
at common/arm_switchcontext.c:95
#1 0x2000001c in g_uart0port ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
This fails for any non-current thread, but works in version 12.5.1.
In version 12.8 GDB can't find any other threads (though g_pidhash[2] is
the TCB pointer for the nsh_main thread):
peter@legion:~/git/nuttx-9/nuttx$ gdb-multiarch nuttx -ex "source tools/gdb/__init__.py"
-ex"target remote 127.0.0.1:1234"
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
...
Remote debugging using 127.0.0.1:1234
0x00007860 in up_idle () at chip/common/tiva_idle.c:64
64 }
(gdb) i thread
Id Target Id Frame
* 1 Thread 1.1 (CPU#0 [halted ]) 0x00007860 in up_idle ()
at chip/common/tiva_idle.c:64
(gdb) thread 2
Unknown thread 2.
(gdb) p g_pidhash
$1 = (struct tcb_s **) 0x20005590
(gdb) p g_npidhash
$2 = 16
(gdb) x/16x g_pidhash
0x20005590: 0x20000a58 0x20005788 0x20006058 0x20006f90
0x200055a0: 0x20008af8 0x00000000 0x00000000 0x00000000
0x200055b0: 0x00000000 0x00000000 0x00000000 0x00000000
0x200055c0: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb) (gdb) p g_pidhash[2].pid
$3 = 2
(gdb) p g_pidhash[2].name
$4 = "nsh_main", '\000' <repeats 16 times>
(gdb)
Any idea why gdb can't unwind a thread's call stack in version 12.6 (or
even access threads in version 12.8)? Outside of the sparse tags in
git, does anyone have a suggestion on how to best bisect to find where
the issue(s) cropped up(especially since nuttx and apps are in separate
repos)?
Thanks in advance!
--
Peter Barada
peter.bar...@gmail.com
