Hacker News Reader

Comment by exDM69 | Hacker News Reader

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

View on HN

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

thanks for sharing! qemu is very powerful, but it’s hard to discocer a lot of these features

Record & replay sounds really nice, but the actual reverse-debugging is broken, see https://gitlab.com/qemu-project/qemu/-/issues/2634

> 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)

Reply on news.ycombinator.com