Testing the toolchain – GDB

As a final step of testing the toolchain, I tried GDB with the CH32V103R Mini Evaluation board. Unfortunately, the binaries that I built in this post didn’t include a binary of the GDB command. Therefore, I rebuilt the toolchain with the following revised ct-ng menuconfig options.

  • In the Target options menu, I enabled the Build a multilib toolchain.
  • In the C-library menu, I selected the newlib as the C library.
  • In the Companion libraries menu, I selected the newlib-nano and enabled the Additionally install newlib-nano libs into TARGET dir option for the newlib-nano.
  • In the Debug facilities menu, I enabled the gdb. (*New)

After removing the previous ${HOME}/x-tools directory, I built the toolchain that includes the GDB command.

sudo apt install python3-distutils python3-dev<br>ct-ng build

Please note that I installed additional python related packages to build GDB with Crosstool-NG.

I tested the riscv32-unknown-elf-gdb using the same CH32V103 example as the previous post. To generate debug information I added -g and -O0 to the GCC options in the Makefile (Here is the updated file).
I ran the openocd separately in a different terminal first as follows.

sudo ./openocd -f wch-riscv.cfg

Then I ran riscv32-unknown-elf-gdb and executed the following commands in the GDB (I typed in the bolded part).

nc-pin$ riscv32-unknown-elf-gdb
GNU gdb (crosstool-NG 1.25.0_rc2.1_7e21141) 11.2
Copyright (C) 2022 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 "--host=x86_64-build_pc-linux-gnu --target=riscv32-unknown-elf".
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".
(gdb) set mem inaccessible-by-default off
(gdb) set architecture riscv:rv32
The target architecture is set to "riscv:rv32".
(gdb) set remotetimeout unlimited
(gdb) file exiti0.elf
Reading symbols from exiti0.elf...
(gdb) target extended-remote :3333
Remote debugging using :3333
HardFault_Handler () at ch32v10x_it.c:40
40	    while(1)
(gdb) load exiti0.elf
Loading section .init, size 0x38 lma 0x0
Loading section .vector, size 0x108 lma 0x38
Loading section .text, size 0x2a60 lma 0x140
Loading section .data, size 0x84 lma 0x2ba0
Start address 0x00000000, load size 11300
Transfer rate: 4 KB/sec, 2825 bytes/write.
(gdb)

Then I set a breakpoint at line 73 of the main.c and let the GDB continue to the breakpoint.

 (gdb) break main.c:73
Breakpoint 1 at 0x17f6: file main.c, line 73.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) cont
Continuing.

Breakpoint 1, main () at main.c:73
Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xcd in position 449: invalid continuation byte
73	    printf("EXTI0 Test\r\n");
(gdb)

After inputting the cont command to the GDB, I saw the output of printf("SystemClk:%d\r\n", SystemCoreClock); at line 71 of the main.c on the UART connection from the CH32V103. I also tried several next commands.

(gdb) next
78	        Delay_Ms(1000);
(gdb) next
79	        printf("Run at main\r\n");
(gdb) next
78	        Delay_Ms(1000);
(gdb) next
79	        printf("Run at main\r\n");
(gdb) next
78	        Delay_Ms(1000);
(gdb)

This time I just tried the limited number of the GDB commands. However, it looked that the GDB I built was working as expected.