| .. _gdbstub: |
| |
| GDB stub |
| ######## |
| |
| .. contents:: |
| :local: |
| :depth: 2 |
| |
| Overview |
| ******** |
| |
| The gdbstub feature provides an implementation of the GDB Remote |
| Serial Protocol (RSP) that allows you to remotely debug Zephyr |
| using GDB. |
| |
| The protocol supports different connection types: serial, UDP/IP and |
| TCP/IP. Zephyr currently supports only serial device communication. |
| |
| The GDB program acts as the client while Zephyr acts as the |
| server. When this feature is enabled, Zephyr stops its execution after |
| :c:func:`gdb_init` starts gdbstub service and waits for a GDB |
| connection. Once a connection is established it is possible to |
| synchronously interact with Zephyr. Note that currently it is not |
| possible to asynchronously send commands to the target. |
| |
| Features |
| ******** |
| |
| The following features are supported: |
| |
| * Add and remove breakpoints |
| * Continue and step the target |
| * Print backtrace |
| * Read or write general registers |
| * Read or write the memory |
| |
| Enabling GDB Stub |
| ***************** |
| |
| GDB stub can be enabled with the :kconfig:option:`CONFIG_GDBSTUB` option. |
| |
| Using Serial Backend |
| ==================== |
| |
| The serial backend for GDB stub can be enabled with |
| the :kconfig:option:`CONFIG_GDBSTUB_SERIAL_BACKEND` option. |
| |
| Since serial backend utilizes UART devices to send and receive GDB commands, |
| |
| * If there are spare UART devices on the board, set ``zephyr,gdbstub-uart`` |
| property of the chosen node to the spare UART device so that :c:func:`printk` |
| and log messages are not being printed to the same UART device used for GDB. |
| |
| * For boards with only one UART device, :c:func:`printk` and logging |
| must be disabled if they are also using the same UART device for output. |
| GDB related messages may interleave with log messages which may have |
| unintended consequences. Usually this can be done by disabling |
| :kconfig:option:`CONFIG_PRINTK` and :kconfig:option:`CONFIG_LOG`. |
| |
| Debugging |
| ********* |
| |
| Using Serial Backend |
| ==================== |
| |
| #. Build with GDB stub and serial backend enabled. |
| |
| #. Flash built image onto board and reset the board. |
| |
| * Execution should now be paused at :c:func:`gdb_init`. |
| |
| #. Execute GDB on development machine and connect to the GDB stub. |
| |
| .. code-block:: bash |
| |
| target remote <serial device> |
| |
| For example, |
| |
| .. code-block:: bash |
| |
| target remote /dev/ttyUSB1 |
| |
| #. GDB commands can be used to start debugging. |
| |
| Example |
| ******* |
| |
| This is an example to demonstrate how GDB stub works. |
| You can also refer to ``tests/subsys/debug/gdbstub`` |
| for its implementation as a Twister test. |
| |
| #. Open two terminal windows. |
| |
| #. On the first terminal, build and run the sample: |
| |
| .. zephyr-app-commands:: |
| :zephyr-app: samples/subsys/debug/gdbstub |
| :host-os: unix |
| :board: qemu_x86 |
| :goals: build run |
| |
| #. On the second terminal, start GDB: |
| |
| .. code-block:: bash |
| |
| <SDK install directory>/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gdb |
| |
| #. Tell GDB where to look for the built ELF file: |
| |
| .. code-block:: text |
| |
| (gdb) file <build directory>/zephyr/zephyr.elf |
| |
| Response from GDB: |
| |
| .. code-block:: text |
| |
| Reading symbols from <build directory>/zephyr/zephyr.elf... |
| |
| #. Tell GDB to connect to the server: |
| |
| .. code-block:: text |
| |
| (gdb) target remote localhost:5678 |
| |
| Note that QEMU is setup to redirect the serial used for GDB stub in |
| the Zephyr image to a networking port. Hence the connection to |
| localhost, port 5678. |
| |
| Response from GDB: |
| |
| .. code-block:: text |
| |
| Remote debugging using :5678 |
| arch_gdb_init () at <ZEPHYR_BASE>/arch/x86/core/ia32/gdbstub.c:232 |
| 232 } |
| |
| GDB also shows where the code execution is stopped. In this case, |
| it is at :file:`arch/x86/core/ia32/gdbstub.c`, line 232. |
| |
| #. Use command ``bt`` or ``backtrace`` to show the backtrace of stack frames. |
| |
| .. code-block:: text |
| |
| (gdb) bt |
| #0 arch_gdb_init () at <ZEPHYR_BASE>/arch/x86/core/ia32/gdbstub.c:232 |
| #1 0x00105068 in gdb_init (arg=0x0) at <ZEPHYR_BASE>/subsys/debug/gdbstub.c:833 |
| #2 0x00109d6f in z_sys_init_run_level (level=0x1) at <ZEPHYR_BASE>/kernel/device.c:72 |
| #3 0x0010a40b in z_cstart () at <ZEPHYR_BASE>/kernel/init.c:423 |
| #4 0x00105383 in z_prep_c (arg=0x9500) at <ZEPHYR_BASE>/arch/x86/core/prep_c.c:58 |
| #5 0x001000a9 in __csSet () at <ZEPHYR_BASE>/arch/x86/core/ia32/crt0.S:273 |
| |
| #. Use command ``list`` to show the source code and surroundings where |
| code execution is stopped. |
| |
| .. code-block:: text |
| |
| (gdb) list |
| 227 } |
| 228 |
| 229 void arch_gdb_init(void) |
| 230 { |
| 231 __asm__ volatile ("int3"); |
| 232 } |
| 233 |
| 234 /* Hook current IDT. */ |
| 235 _EXCEPTION_CONNECT_NOCODE(z_gdb_debug_isr, IV_DEBUG, 3); |
| 236 _EXCEPTION_CONNECT_NOCODE(z_gdb_break_isr, IV_BREAKPOINT, 3); |
| |
| #. Use command ``s`` or ``step`` to step through program until it reaches |
| a different source line. Now that it finished executing :c:func:`arch_gdb_init` |
| and is continuing in :c:func:`gdb_init`. |
| |
| .. code-block:: text |
| |
| (gdb) s |
| gdb_init (arg=0x0) at /home/dleung5/zephyr/rtos/zephyr/subsys/debug/gdbstub.c:834 |
| 834 return 0; |
| |
| .. code-block:: text |
| |
| (gdb) list |
| 829 LOG_ERR("Could not initialize gdbstub backend."); |
| 830 return -1; |
| 831 } |
| 832 |
| 833 arch_gdb_init(); |
| 834 return 0; |
| 835 } |
| 836 |
| 837 #ifdef CONFIG_XTENSA |
| 838 /* |
| |
| #. Use command ``br`` or ``break`` to setup a breakpoint. This example |
| sets up a breakpoint at :c:func:`main`, and let code execution continue |
| without any intervention using command ``c`` (or ``continue``). |
| |
| .. code-block:: text |
| |
| (gdb) break main |
| Breakpoint 1 at 0x1005a9: file <ZEPHYR_BASE>/samples/subsys/debug/gdbstub/src/main.c, line 32. |
| (gdb) continue |
| Continuing. |
| |
| Once code execution reaches :c:func:`main`, execution will be stopped |
| and GDB prompt returns. |
| |
| .. code-block:: text |
| |
| Breakpoint 1, main () at <ZEPHYR_BASE>/samples/subsys/debug/gdbstub/src/main.c:32 |
| 32 ret = test(); |
| |
| Now GDB is waiting at the beginning of :c:func:`main`: |
| |
| .. code-block:: text |
| |
| (gdb) list |
| 27 |
| 28 int main(void) |
| 29 { |
| 30 int ret; |
| 31 |
| 32 ret = test(); |
| 33 printk("%d\n", ret); |
| 34 } |
| 35 |
| 36 K_THREAD_DEFINE(thread, STACKSIZE, thread_entry, NULL, NULL, NULL, |
| |
| #. To examine the value of ``ret``, the command ``p`` or ``print`` |
| can be used. |
| |
| .. code-block:: text |
| |
| (gdb) p ret |
| $1 = 0x11318c |
| |
| Since ``ret`` has not been assigned a value yet, what it contains is |
| simply a random value. |
| |
| #. If step (``s`` or ``step``) is used here, it will continue execution |
| until :c:func:`printk` is reached, thus skipping the interior of |
| :c:func:`test`. To examine code execution inside :c:func:`test`, |
| a breakpoint can be set for :c:func:`test`, or simply using |
| ``si`` (or ``stepi``) to execute one machine instruction, where it has |
| the side effect of going into the function. |
| |
| .. code-block:: text |
| |
| (gdb) si |
| test () at <ZEPHYR_BASE>/samples/subsys/debug/gdbstub/src/main.c:13 |
| 13 { |
| (gdb) list |
| 8 #include <zephyr/sys/printk.h> |
| 9 |
| 10 #define STACKSIZE 512 |
| 11 |
| 12 static int test(void) |
| 13 { |
| 14 int a; |
| 15 int b; |
| 16 |
| 17 a = 10; |
| |
| #. Here, ``step`` can be used to go through all code inside :c:func:`test` |
| until it returns. Or the command ``finish`` can be used to continue |
| execution without intervention until the function returns. |
| |
| .. code-block:: text |
| |
| (gdb) finish |
| Run till exit from #0 test () at <ZEPHYR_BASE>/samples/subsys/debug/gdbstub/src/main.c:13 |
| 0x001005ae in main () at <ZEPHYR_BASE>/samples/subsys/debug/gdbstub/src/main.c:32 |
| 32 ret = test(); |
| Value returned is $2 = 0x1e |
| |
| And now, execution is back to :c:func:`main`. |
| |
| #. Examine ``ret`` again which should have the return value from |
| :c:func:`test`. Sometimes, the assignment is not done until another |
| ``step`` is issued, as in this case. This is due to the assignment |
| code is done after returning from function. The assignment code is |
| generated by the toolchain as machine instructions which are not |
| visible when viewing the corresponding C source file. |
| |
| .. code-block:: text |
| |
| (gdb) p ret |
| $3 = 0x11318c |
| (gdb) s |
| 33 printk("%d\n", ret); |
| (gdb) p ret |
| $4 = 0x1e |
| |
| #. If ``continue`` is issued here, code execution will continue indefinitely |
| as there are no breakpoints to further stop execution. Breaking execution |
| in GDB via Ctrl-C does not currently work as the GDB stub does not |
| support this functionality (yet). |
