This is an automated email from the ASF dual-hosted git repository.
acassis pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new 224a8f4b28 Documentation: fix nuttxgdb related commands
224a8f4b28 is described below
commit 224a8f4b28b6b473a4dd504221af7f3a183d7b85
Author: Neo Xu <neo.xu1...@gmail.com>
AuthorDate: Tue Nov 26 00:28:31 2024 +0800
Documentation: fix nuttxgdb related commands
Now we should load tools/gdb/gdbinit.py script
Signed-off-by: Neo Xu <neo.xu1...@gmail.com>
---
Documentation/guides/gdbwithpython.rst | 20 +++++-----
Documentation/guides/qemugdb.rst | 45 ++++++++++++----------
.../risc-v/qemu-rv/boards/rv-virt/index.rst | 2 +-
Documentation/quickstart/debugging.rst | 6 +--
4 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/Documentation/guides/gdbwithpython.rst
b/Documentation/guides/gdbwithpython.rst
index 2f1d895b0d..b12f27186f 100644
--- a/Documentation/guides/gdbwithpython.rst
+++ b/Documentation/guides/gdbwithpython.rst
@@ -5,23 +5,23 @@ GDB with Python
Introduction
============
-We can better debug the nuttx kernel through GDB's python extension.
-Some of the most common class usages are implemented under the nuttx/tools/gdb
directory.
-Users can write their own python scripts to debug the nuttx kernel according
to their needs
+The NuttX kernel can be effectively debugged using GDB's Python extension.
+Commonly used classes and utilities are implemented in the
nuttx/tools/gdb/nuttxgdb directory.
+Users can also create custom Python scripts tailored to their debugging needs
to analyze and troubleshoot the NuttX kernel more efficiently.
Usage
=====
-1. Compile nuttx with CONFIG_DEBUG_SYMBOLS=y
-2. Use gdb to debug nuttx elf.(real device, or sim, or coredump)
-3. add args to gdb command line: -ix="nuttx/tools/gdb/__init__.py"
-4. Then gdb will load the python script automatically.you can use the custom
commands.
+1. Compile NuttX with CONFIG_DEBUG_SYMBOLS=y enabled and change
`CONFIG_DEBUG_SYMBOLS_LEVEL` to -g3.
+2. Use GDB to debug the NuttX ELF binary (on a real device, a simulator, or
with a coredump).
+3. Add the following argument to the GDB command line:
`-ix="nuttx/tools/gdb/gdbinit.py"`
+4. GDB will automatically load the Python script, enabling the use of custom
commands.
How to write a GDB python script
================================
-Here is an article to introduce, read it to understand the most basic
principles of python,
+Here is an article that introduces the fundamental principles of Python in
GDB. Read it to gain a basic understanding.
`Automate Debugging with GDB Python API
<https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
-For more documentation on gdb python, please refer to the official
documentation of gdb
-`GDB with python
<https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
+For more documentation on gdb python, please refer to the official
documentation of GDB.
+`GDB Python API
<https://sourceware.org/gdb/current/onlinedocs/gdb.html/Python-API.html#Python-API>`_.
diff --git a/Documentation/guides/qemugdb.rst b/Documentation/guides/qemugdb.rst
index e071e06ea5..8a6921009a 100644
--- a/Documentation/guides/qemugdb.rst
+++ b/Documentation/guides/qemugdb.rst
@@ -18,7 +18,7 @@ Compiling
There is a sample configuration to use lm3s6965-ek on QEMU.
- Just use ``lm3s6965-ek:qemu-flat`` board profile for this purpose.
+ Just use ``lm3s6965-ek:qemu-flat`` board profile for this purpose.
.. code-block:: console
@@ -34,7 +34,7 @@ Compiling
Start QEMU
==========
-#. You need to start QEMU using the nuttx ELF file just create above:
+#. You need to start QEMU using the NuttX ELF file just create above:
.. code-block:: console
@@ -42,7 +42,7 @@ Start QEMU
Timer with period zero, disabling
ABCDF
telnetd [4:100]
-
+
NuttShell (NSH) NuttX-12.0.0
nsh>
@@ -53,23 +53,27 @@ Start GDB to connect to QEMU
.. code-block:: console
- $ gdb-multiarch nuttx -ex "source tools/gdb/__init__.py" -ex "target
remote 127.0.0.1:1234"
- Type "apropos word" to search for commands related to "word"...
- Reading symbols from nuttx...
- set pagination off
- source tools/gdb/lists.py
- source tools/gdb/utils.py
- source tools/gdb/memdump.py
-
- if use thread command, please don't use 'continue', use 'c' instead !!!
- source tools/gdb/thread.py
- "handle SIGUSR1 "nostop" "pass" "noprint"
- Remote debugging using 127.0.0.1:1234
- 0x0000a45a in up_idle () at chip/common/tiva_idle.c:62
- 62 }
- (gdb)
+ $ gdb-multiarch nuttx -ex "source tools/gdb/gdbinit.py" -ex "target
remote 127.0.0.1:1234"
+ Reading symbols from nuttx...
+ Registering NuttX GDB commands from ~/nuttx/nuttx/tools/gdb/nuttxgdb
+ set pagination off
+ set python print-stack full
+ "handle SIGUSR1 "nostop" "pass" "noprint"
+ Load macro: ~/nuttx/nuttx/b73e7dbb3d3bbd6ff2eb9be4e5f01d5e.json
+ readelf took 0.1 seconds
+ Parse macro took 0.1 seconds
+ Cache macro info to ~/nuttx/nuttx/b73e7dbb3d3bbd6ff2eb9be4e5f01d5e.json
+
+ if use thread command, please don't use 'continue', use 'c' instead !!!
+ if use thread command, please don't use 'step', use 's' instead !!!
+ Build version: "86868a9e194-dirty Nov 26 2024 00:14:53"
-#. From (gdb) prompt you can run commands to inpect NuttX:
+ Remote debugging using :1234
+ 0x0000b78a in up_idle () at chip/common/tiva_idle.c:62
+ 62 }
+ (gdb)
+
+#. From (gdb) prompt you can run commands to inspect NuttX:
.. code-block:: console
@@ -80,7 +84,6 @@ Start GDB to connect to QEMU
2 Thread 0x20005e30 (Name: nsh_main, State: Waiting,Semaphore,
Priority: 100, Stack: 2008) 0xa68c up_switch_context() at
common/arm_switchcontext.c:95
3 Thread 0x20006d48 (Name: NTP_daemon, State: Waiting,Signal,
Priority: 100, Stack: 1960) 0xa68c up_switch_context() at
common/arm_switchcontext.c:95
4 Thread 0x20008b60 (Name: telnetd, State: Waiting,Semaphore,
Priority: 100, Stack: 2016) 0xa68c up_switch_context() at
common/arm_switchcontext.c:95
- (gdb)
+ (gdb)
As you can see QEMU and GDB are powerful tools to debug NuttX without using
external board or expensive debugging hardware.
-
diff --git a/Documentation/platforms/risc-v/qemu-rv/boards/rv-virt/index.rst
b/Documentation/platforms/risc-v/qemu-rv/boards/rv-virt/index.rst
index 7db24177a4..8749b121eb 100644
--- a/Documentation/platforms/risc-v/qemu-rv/boards/rv-virt/index.rst
+++ b/Documentation/platforms/risc-v/qemu-rv/boards/rv-virt/index.rst
@@ -416,7 +416,7 @@ After building the kernel (and the applications, in kernel
mode), use the toolch
to debug RISC-V applications. For instance, if you are using the xPack's
prebuilt toolchain,
you can use the following command to start GDB::
- $ riscv-none-elf-gdb-py3 -ix tools/gdb/__init__.py --tui nuttx
+ $ riscv-none-elf-gdb-py3 -ix tools/gdb/gdbinit.py --tui nuttx
To use QEMU for debugging, one should add the parameters ``-s -S`` to the QEMU
command line.
diff --git a/Documentation/quickstart/debugging.rst
b/Documentation/quickstart/debugging.rst
index 53444449c9..1101e0747c 100644
--- a/Documentation/quickstart/debugging.rst
+++ b/Documentation/quickstart/debugging.rst
@@ -236,7 +236,7 @@ Now, You can now inspect threads:
faultmask 0x0 0
control 0x0 0
-With gdb
+With GDB
~~~~~~~~
You can also do NuttX aware debugging using ``gdb`` scripting support.
@@ -244,12 +244,12 @@ The benefit is that it works also for the sim build where
``openocd`` is
not applicable. For this to work, you will need to enable PROC filesystem
support
which will expose required task information (``CONFIG_FS_PROCFS=y``).
-To use this approach, you can load the ``nuttx/tools/gdb/__init__.py`` file. An
+To use this approach, you can load the ``nuttx/tools/gdb/gdbinit.py`` file. An
easy way to do this is to add an extra command:
.. code-block:: console
- $ gdb nuttx -ix=tools/gdb/__init__.py
+ $ gdb nuttx -ix=tools/gdb/gdbinit.py
gdb can need to set the current elf support architecture, for example,
the prefix is arm-ebai-none-.
