Previously, we discussed how to run the RISC-V kernel on QEMU. Now, let’s talk about how to use Eclipse + GDB to debug the kernel on the QEMU platform.
${SIFIVE_DIR} is the local root directory of the freedom-u-sdk open-source project.
1. Configure BBL
Configure the bootloader and generate debugging information.
Enter the ${SIFIVE_DIR}/work/riscv-pk directory, which is the directory for compiling riscv-pk.
Execute the following commands:
|
rm $SIFIVE_DIR/work/riscv-pk/* cd $SIFIVE_DIR/work/riscv-pk PATH=$SIFIVE_DIR/work/buildroot_initramfs/host/bin:$PATH $SIFIVE_DIR/riscv-pk/configure \ CFLAGS=”-mabi=lp64d -march=rv64imafdc -g” LDFLAGS=’-g’ make PATH=$SIFIVE_DIR/work/buildroot_initramfs/host/bin:$PATH -C $SIFIVE_DIR/work/riscv-pk |
The main thing is to add the -g parameter to the CFLAGS and LDFLAGS variables.
After compilation, use readelf -S bbl to check if the generated bbl contains debugging information. It should have a .debug* section.
2. Configure Kernel
Configure the kernel and generate debugging information.
Enter the ${SIFIVE_DIR}/linux directory, and execute make ARCH=riscv menuconfig O=${SIFIVE_DIR}/work/linux.
The O option specifies the directory for the Linux kernel compilation.
On the kernel hacking -> compile-time checks and compiler options page, check the first option: Compile the kernel with debug info.
Re-run make O=${SIFIVE_DIR}/work/linux vmlinux to generate vmlinux.
Use readelf -S vmlinux to check the sections of vmlinux; if there is a .debug** section as shown below, it indicates that vmlinux contains debugging information.
3. Starting QEMU in Debug Mode
The -s and -S parameters of QEMU can start in debug mode.
|
$SIFIVE_DIR/work/riscv-qemu/prefix/bin/qemu-system-riscv64 -nographic -machine virt -bios $SIFIVE_DIR/work/riscv-pk/bbl -kernel $SIFIVE_DIR/work/linux/vmlinux -initrd $SIFIVE_DIR/work/initramfs.cpio.gz -netdev user,id=net0 -device virtio-net-device,netdev=net0 -s -S |
4. Connecting Eclipse
Start the Eclipse tool and create a project.
After the project is created, configure the debug settings.
On the main interface, select the project you just created and check Disable auto build.
On the debugger interface, select gdbserver, and configure the path for the DGB debugger, using riscv64-unknown-linux-gnu-gdb here.
The GDB version on my machine is 8.2.
|
lujun@lujun-host:~$ /opt/riscv-gcc/bin/riscv64-unknown-linux-gnu-gdb -version GNU gdb (GDB) 8.2.50.20181127-git Copyright (C) 2018 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. |
On the connection options page, fill in localhost for the hostname and 1234 for the port. The -s option of QEMU will create port 1234 for GDB connection debugging.
After setting up, select debug at the bottom right corner to start debugging.
5. Debugging BBL
After starting debugging, in the debug sub-interface, select Process[1]->Thread#11->0x1000. 0x1000 indicates that the CPU has stopped at address 0x1000, which is the reset address of riscv-qemu.
Click view Disassembly to see the disassembly.
In the console interface, there will be a warning message, and the disassembly at address 0x1000 will not be displayed. This is because the instructions executed by the CPU are hardcoded in QEMU and cannot be debugged at this point.
|
Type “apropos word” to search for commands related to “word”. warning: No executable has been specified and target does not support determining executable automatically. Try using the “file” command. 0x0000000000001000 in ?? () |
In the console interface, enter the following command to load bbl and set a breakpoint at the starting label of bbl:
|
file /home/lujun/work/sifive/freedom-u-sdk/work/riscv-pk/bbl b reset_vector |
The execution result is as follows:
|
file /home/lujun/work/sifive/freedom-u-sdk/work/riscv-pk/bbl A program is being debugged already. Are you sure you want to change the file? (y or n) [answered Y; input not from terminal] Reading symbols from /home/lujun/work/sifive/freedom-u-sdk/work/riscv-pk/bbl… b reset_vector Breakpoint 1 at 0x80000000: file /home/lujun/work/sifive/freedom-u-sdk/riscv-pk/machine/mentry.S, line 37. |
The file command loads an ELF program. The b command sets a breakpoint. The starting execution label of bbl is reset_vector.
Click the run button in Eclipse to start execution. After a while, the CPU will stop at the set breakpoint, allowing us to debug the bbl program.
6. Debugging the Kernel
Use the file command to load vmlinux and set a breakpoint at start_kernel.
|
file /home/lujun/work/sifive/freedom-u-sdk/work/linux/vmlinux A program is being debugged already. Are you sure you want to change the file? (y or n) [answered Y; input not from terminal] Load new symbol table from “/home/lujun/work/sifive/freedom-u-sdk/work/linux/vmlinux”? (y or n) [answered Y; input not from terminal] Reading symbols from /home/lujun/work/sifive/freedom-u-sdk/work/linux/vmlinux… Error in re-setting breakpoint 1: Function “reset_vector” not defined. b start_kernel Breakpoint 2 at 0xffffffe00000063c: file /home/lujun/work/sifive/freedom-u-sdk/linux/init/main.c, line 536. |
Click the run button in Eclipse to start execution. After a while, the CPU will stop at the set breakpoint, allowing us to debug the kernel program.
7. Conclusion
With the help of QEMU, Eclipse, and GDB tools, we can debug both the bbl and kernel.
This version of GDB has some issues, requiring code modifications and recompilation. When encountering issues, just search for the error results on Baidu, follow the suggestions to modify the code, and recompile.
