hbreak does not work in gdb for a KVM guest

[z0rr0]

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:

Code: Select all

(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x000000000000fff0 in ?? ()
(gdb) hbreak KERNELSTART
Hardware assisted breakpoint 1 at 0x42abc0: file ../../rtl/Kernel.pas, line 55.
(gdb) c
Continuing.
[Inferior 1 (process 1) exited normally]
(gdb)

QEMU just finishes after this. When using software breakpoints, e.g., "b", the breakpoint is caught but then the same problem when continuing:

Code: Select all

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.

Thanks,

[bzt]

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

Code: Select all

jmp $

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:

Code: Select all

set $pc += 2

then use single step from there. You can find these and other tricks on the wiki.

Cheers,
bzt

[z0rr0]

Thanks for your answer. I am afraid that neither "s" nor "si" works. I am doing "b CurrentLine+1" to do a step-by-step execution.

[z0rr0]

So I think the only way is to develop a built-in kernel debugger for my kernel.

[bzt]

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.

Cheers,
bzt

[z0rr0]

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.

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.

[bzt]

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

Code: Select all

set architecture i386:x86-64
target remote localhost:1234
symbol-file (your elf kernel here)

? 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.

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

Cheers,
bzt

[z0rr0]

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":

Code: Select all

[email protected]:kvm_run_exit cpu_index 0, reason 4

The "4" means KVM_EXIT_DEBUG. However, it seems that the gdbstub is never notified.

[z0rr0]

Hello, I ended up implementing a simple gdbstub. You can follow the progress at https://github.com/torokernel/torokerne ... dbstub.pas.

Cheers,