Hello, I am using gdb to debug my kernel running as a KVM guest. However, the execution does not stop in the breakpoint that I set up by using "hbreak". I found that this problem is common and somehow works out for Linux guests. Am I missing something? Does this require any other tweak? This is the output of gdb:
Breakpoint 1, KERNELSTART () at ../../rtl/Kernel.pas:55 55 begin (gdb) c Continuing. [Inferior 1 (process 1) exited normally]
And QEMU finishes as before. After testing a bit, I figured out that "b" works well if I set the breakpoint after the guest has booted in long-mode. But the step command does not work. The only way to go to the next step is to set a breakpoint in the next line.
z0rr0 wrote:Hello, I am using gdb to debug my kernel running as a KVM guest. However, the execution does not stop in the breakpoint that I set up by using "hbreak". I found that this problem is common and somehow works out for Linux guests. Am I missing something? Does this require any other tweak?
You are right, this is a known problem. Breakpoint doesn't work with kvm enabled. You either turn it off and rely on software emulation (which is slow, but works), or like Linux, you incorporate gdb-server into your kernel, so that it can talk to gdb directly.
An easy way out is this: you use the gdb-server built into qemu, and you place a
instruction in your code where you want the break. Then you start gdb, and when your vm hangs, you press Ctrl+C to get to the gdb prompt. There you jump over the blocking instruction:
z0rr0 wrote:So I think the only way is to develop a built-in kernel debugger for my kernel.
Well, that "jmp $" tricks works really great. But if you want to debug your kernel on real machines (sooner or later you'll want to), then having a built-in debugger is the best option.
Here is a very minimal one (ca. 300 SLoC). It is written for ARM, so in order to use it for x86_64, 1. replace uart.c with one that uses the 0x3f8 port 2. rewrite dbg_saveregs in start.S to save x86_64 registers and the ISR handlers to use x86_64 IDT 3. remove the disassembler by setting DISASSEMBLER define to 0 in dbg.c That's about it.
bzt wrote:Well, that "jmp $" tricks works really great. But if you want to debug your kernel on real machines (sooner or later you'll want to), then having a built-in debugger is the best option.
Yes, that's also a possibility. However, I could not make "si" work. Additional steps would require modifying my IDE to allow graphical step-by-step execution which is actually the final goal.
bzt wrote:Here is a very minimal one (ca. 300 SLoC). It is written for ARM, so in order to use it for x86_64, 1. replace uart.c with one that uses the 0x3f8 port 2. rewrite dbg_saveregs in start.S to save x86_64 registers and the ISR handlers to use x86_64 IDT 3. remove the disassembler by setting DISASSEMBLER define to 0 in dbg.c That's about it.
Cheers, bzt
Thanks, I will check it. The other option is to try to figure out why the gdbstub in QEMU does not work in this case and fix it.
z0rr0 wrote:Yes, that's also a possibility. However, I could not make "si" work.
Honestly, I have never ever issues with that. It always "just works" (TM) for me. Did you set the correct architecture and image file in gdb? For long mode, something like
? Gdb is very strict on having the correct symbols, you can't just disassemble or execute if the memory pointed by RIP is not inside a function.
z0rr0 wrote:Thanks, I will check it. The other option is to try to figure out why the gdbstub in QEMU does not work in this case and fix it.
That won't help you when you'll finally move to test on real machine. But lucky for you (and others who'll come after you), I've quickly put together a mini debugger. Works for ARM (AArch64) and PC (x86_64), and uses the serial port to connect to a VT terminal (or some kind of emulator like PuTTY and minicom running on another PC).
bzt wrote:That won't help you when you'll finally move to test on real machine. But lucky for you (and others who'll come after you), I've quickly put together a mini debugger. Works for ARM (AArch64) and PC (x86_64), and uses the serial port to connect to a VT terminal (or some kind of emulator like PuTTY and minicom running on another PC). bzt
Thanks, I will check that. My kernel is meant to boot as KVM guest though. I debugged a bit by using Qemu and trace-points and I can see that there are many VMEXITS when I use "hbreak":