3 ms·
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
by exDM69 2y 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.
https://qemu-project.gitlab.io/qemu/system/gdb.html https://qemu-project.gitlab.io/qemu/system/gdb.html
- o11c 2y ago> 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)
- quruquru 2y agoAgree, 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 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
- kotborealis 2y agoRecord & replay sounds really nice, but the actual reverse-debugging is broken, see https://gitlab.com/qemu-project/qemu/-/issues/2634 https://gitlab.com/qemu-project/qemu/-/issues/2634
- jannesan 2y agothanks for sharing! qemu is very powerful, but it’s hard to discocer a lot of these features