On 1/23/25 19:20, Tomek CEDRO wrote:
Hey there Peter :-)
Are you sure this is not a bug in gdb?
If not, then this is called thread aware debug and probably gdb
changed some api or invocation parameters if that still works in older
versions. Maybe simple update to tools/gdb/__init__.py will do the
job?
The GDB version is the same - and as far as I can tell, the thread
decoding is from the python code supplied by Nuttx via the
release-dependent .py code to tell GDB how to figure out the thread
frame(which I hope is consistent with whatever changes occur
per-release). I'd expect if it was dependent on GDB then there would
be version restriction/recommendations in the instructions...
Looking further, I got the GDB command args wrong for version for 12.8
(12.8 calls for gdbinit.py, not __init__.py), here's updated 12.8
output (which allows looking at threads and nsh_main callstack, but
generates warnings on start):
peter@legion:~/git/nuttx-9/nuttx$ gdb-multiarch nuttx -ex "source
tools/gdb/gdbinit.py" -ex"target remote 127.0.0.1:1234"
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
later<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nuttx...
Registering NuttX GDB commands from
/home/peter/git/nuttx-9/nuttx/tools/gdb/nuttxgdb
set pagination off
set python print-stack full
"handle SIGUSR1 "nostop" "pass" "noprint"
Load macro: /tmp/6482983066076f4840874fa49f322c94.json
readelf took 0.0 seconds
Parse macro took 0.0 seconds
Cache macro info to /tmp/6482983066076f4840874fa49f322c94.json
*Ignore module: fs, error: int() argument must be a string, a
bytes-like object or a real number, not 'NoneType' Traceback (most
recent call last): * File
"/home/peter/git/nuttx-9/nuttx/tools/gdb/nuttxgdb/__init__.py", line
54, in init_gdb_commands
module = importlib.import_module(f"{__package__}.{m}")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/importlib/__init__.py", line 90, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in
_find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 995, in exec_module
File "<frozen importlib._bootstrap>", line 488, in
_call_with_frames_removed
File "/home/peter/git/nuttx-9/nuttx/tools/gdb/nuttxgdb/fs.py", line
39, in <module>
CONFIG_NFILE_DESCRIPTORS_PER_BLOCK = int(
^^^^
*TypeError: int() argument must be a string, a bytes-like object or a
real number, not 'NoneType' *
if use thread command, please don't use 'continue', use 'c' instead !!!
if use thread command, please don't use 'step', use 's' instead !!!
Please pip install debugpyPlease pip install pyelftools
Please pip install numpy
Please pip install matplotlib
Build version: "3bf704ad13 Jan 23 2025 16:35:47"
Remote debugging using 127.0.0.1:1234
0x00007860 in up_idle () at chip/common/tiva_idle.c:64
64 }
(gdb) i thread
Index Tid Pid Thread Info Frame
*0 0 0 Thread 0x20000a58 (Name: Idle_Task, State:
Running, Priority: 0, Stack: 1008) 0x7860[ up_idle() at
chip/common/tiva_idle.c:64
1 1 0 Thread 0x20005788 (Name: hpwork, State:
Waiting,Semaphore, Priority: 224, Stack: 1984) 0x2480[ nxsem_wait()
at semaphore/sem_wait.c:202
2 2 2 Thread 0x20006058 (Name: nsh_main, State:
Waiting,Semaphore, Priority: 100, Stack: 2008) 0x2480[ nxsem_wait()
at semaphore/sem_wait.c:202
3 3 3 Thread 0x20006f90 (Name: NTP_daemon, State:
Waiting,Signal, Priority: 100, Stack: 1960) 0x48ca[ nxsig_clockwait()
at signal/sig_timedwait.c:338
4 4 4 Thread 0x20008af8 (Name: telnetd, State:
Waiting,Semaphore, Priority: 100, Stack: 2016) 0x2480[ nxsem_wait()
at semaphore/sem_wait.c:202
(gdb) thread 2
(gdb) where
#0 nxsem_wait_slow (sem=0x20000020 <g_uart0port+32>)
at semaphore/sem_wait.c:202
#1 nxsem_wait (sem=sem@entry=0x20000020 <g_uart0port+32>)
at semaphore/sem_wait.c:270
#2 0x0000552c in uart_read (filep=0x20006388, buffer=0x20006bb7 "",
buflen=1)
at serial/serial.c:1207
#3 0x000159d0 in file_readv_compat (uio=<optimized out>,
filep=0x20006388)
at vfs/fs_read.c:81
#4 file_readv (filep=0x20006388, uio=<optimized out>) at
vfs/fs_read.c:165
#5 0x00015a14 in nx_readv (fd=<optimized out>, iov=iov@entry=0x20006ba0,
iovcnt=iovcnt@entry=1) at vfs/fs_read.c:256
#6 0x00015a28 in readv (fd=<optimized out>, iov=iov@entry=0x20006ba0,
iovcnt=iovcnt@entry=1) at vfs/fs_read.c:318
#7 0x00015a4a in read (fd=<optimized out>, buf=buf@entry=0x20006bb7,
nbytes=nbytes@entry=1) at vfs/fs_read.c:352
#8 0x00008322 in readline_getc (vtbl=0x20006be4) at readline_fd.c:75
#9 0x0000a2bc in readline_common (vtbl=vtbl@entry=0x20006be4,
buf=buf@entry=0x20008a10 "", buflen=buflen@entry=80)
at readline_common.c:515
#10 0x00008398 in readline_fd (buf=buf@entry=0x20008a10 "",
buflen=buflen@entry=80, infd=0, outfd=1) at readline_fd.c:238
#11 0x00008128 in nsh_session (pstate=pstate@entry=0x20008758,
login=login@entry=1, argc=argc@entry=1, argv=argv@entry=0x200064a0)
at nsh_session.c:230
#12 0x00008062 in nsh_consolemain (argc=argc@entry=1,
argv=argv@entry=0x200064a0) at nsh_consolemain.c:77
#13 0x00008034 in nsh_main (argc=1, argv=0x200064a0) at nsh_main.c:76
#14 0x0000613c in nxtask_startup (entrypt=0x8009 <nsh_main>, argc=1,
argv=0x200064a0) at sched/task_startup.c:72
#15 0x00002a26 in nxtask_start () at task/task_start.c:116
#16 0x00000000 in ?? ()
(gdb)
Going back I've verified I'm using the advertised instructions in
https://nuttx.apache.org/docs/12.6.0/guides/qemugdb.html for version
12.6 0- which fail to unwind thread call stacks (outside of the
current thread's stack).
I'm focusing on version 12.6 since I've got customer failures in a
Nuttx-12.6 application(network send() gets stuck) - and hoping if I
can get gdb to be fully thread-aware there then I can dump the call
stacks and walk them to best understand the context of the failure.
Thanks in advance!
