Comment by exDM69
2 years ago
Very delightful article. Based on my experience in "hobby" OS programming, I would add setting up GDB debugging as early as possible. It was a great help in my projects and an improvement over debugging with the QEMU monitor only.
QEMU contains a built-in GDB server, you'll need a GDB client built for the target architecture (riscv in this case) and connecting to the QEMU GDB server over the network.
Agree, and I'll add 3 other really useful QEMU features for osdev:
1) Record & Replay: Record an execution and replay it back. You can even attach GDB while replaying, and go back in time while debugging with "reverse-next" and "reverse-continue": https://qemu-project.gitlab.io/qemu/system/replay.html
2) The QEMU monitor, especially the "gva2gpa" and "xp" commands which are very useful to debug stuff with virtual memory
3) "-d mmu,cpu_reset,guest_errors,unimp": Basically causes QEMU to log when your code does something wrong. Also check "trace:help", there's a bunch of useful stuff to debug drivers
Record & replay sounds really nice, but the actual reverse-debugging is broken, see https://gitlab.com/qemu-project/qemu/-/issues/2634
thanks for sharing! qemu is very powerful, but it’s hard to discocer a lot of these features
> you'll need a GDB client built for the target architecture
Thankfully, GDB has a multiarch build these days which should work for all well-behaved targets in a single build.
(the place it is known to fail is for badly-behaved (embedded?) targets where there are configuration differences but no way to identify them)