Hi Peter,
The error message reported in version 12.8.0 means that macro
`CONFIG_NFILE_DESCRIPTORS_PER_BLOCK` is failed to parse. It may due to
insufficient debug level(`-g3`). But it won't affect other commands like `info
threads` etc.
> 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
Yes. The GDB extension became a standard python package, so we need to import
it instead of call __init__.py. The `__init__.py` is kind of misleading in
previous versions, since it's not a package back then.
The gdbinit.py script is simply to import the package.
The thread awareness debug wasn't changed a lot. You can try the newer version
of python script even on 12.6 where you have customer failure. If it works,
then it works.
As for the issue you met in 12.5.1, I tried but unfortunately cannot reproduce
it.
I followed below steps.
cd nuttx
git checkout nuttx-12.5.1
cd ../apps
git checkout nuttx-12.5.1
cd ../nuttx
tools/configure.sh lm3s6965-ek:qemu-flat
make -j
qemu-system-arm -M lm3s6965evb -device loader,file=nuttx -serial mon:stdio
-nographic -s
gdb-multiarch nuttx -ex "source tools/gdb/__init__.py" -ex "target remote
127.0.0.1:1234"
# Then i thread works
(gdb) i thread
Id Thread Info
Frame
*0 Thread 0x2000169c (Name: Idle_Task, State: Running, Priority: 0,
Stack: 1008) 0xa33e up_idle() at chip/common/tiva_idle.c:62
1 Thread 0x20005258 (Name: hpwork, State: Waiting,Semaphore, Priority:
224, Stack: 1984) 0xa570 up_switch_context() at
common/arm_switchcontext.c:95
2 Thread 0x20005e18 (Name: nsh_main, State: Waiting,Semaphore, Priority:
100, Stack: 2008) 0xa570 up_switch_context() at
common/arm_switchcontext.c:95
3 Thread 0x20006d20 (Name: NTP_daemon, State: Waiting,Semaphore,
Priority: 100, Stack: 1960) 0xa570 up_switch_context() at
common/arm_switchcontext.c:95
4 Thread 0x20008b38 (Name: telnetd, State: Waiting,Semaphore, Priority:
100, Stack: 2016) 0xa570 up_switch_context() at
common/arm_switchcontext.c:95
(gdb)
________________________________
From: Peter Barada <peter.bar...@gmail.com>
Sent: Friday, January 24, 2025 9:22 AM
To: Tomek CEDRO
Cc: Nuttx-dev
Subject: [External Mail]Re: GDB can't show QEMU ARM thread call stack/threads
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈
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!
--
Peter Barada
peter.bar...@gmail.com
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from XIAOMI,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or email immediately and
delete it!******/#
