3. How to Debug¶
3.1. How to debug the security monitor (bbl) and the linux kernel?¶
We use QEMU+GDB to debug the security monitor or the kernel. QEMU is an effective way to debug them.
First compile with debugging symbols
# in your <build directory> cmake -DCMAKE_BUILD_TYPE=Debug ..
build directory where you ran
All cores will immediately hang at the first instruction (i.e., bootrom), waiting for
gdb to be attached.
Now, run a riscv
gdb in another terminal. You can feed it with the
bbl binary or the kernel image to add debug information.
For example, if you want to debug with the
# in your <build directory> riscv64-unknown-linux-gnu-gdb ./sm.build/platform/generic/firmware/fw_payload.elf
If you want to debug with the kernel’s debug information
# in your <build directory> riscv64-unknown-linux-gnu-gdb ./linux.build/vmlinux
Then, attach to QEMU on the port printed by the starting qemu script:
(gdb) target remote localhost:$PORT
Now, you can start debugging the SM (bbl) or the kernel. Try to set breakpoints and run.
Before setting breakpoints, you should run following command:
(gdb) set riscv use_compressed_breakpoints no
To see why we need that command, see this issue
3.2. Logging QEMU debug messages¶
QEMU provides a great option to collect the logs.
If you add
-D [filename] flag to the QEMU command, it will print out the logs into
You can also choose which kind of logs you want to print out, using
-d [options] flag.
./riscv-qemu/riscv64-softmmu/qemu-system-riscv64 -d in_asm -D debug.log #...etc...