OSDev.org

Posted: **Wed Jan 20, 2021 11:31 am**

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,

Posted: **Wed Jan 20, 2021 3:32 pm**

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

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

Posted: **Thu Jan 21, 2021 4:10 pm**

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.

Posted: **Sun Jan 24, 2021 11:02 am**

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

Posted: **Sun Jan 24, 2021 11:27 am**

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.

Cheers,
bzt

Posted: **Sun Jan 24, 2021 12:43 pm**

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.

Posted: **Sun Jan 24, 2021 6:06 pm**

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

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.

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

Cheers,
bzt

Posted: **Tue Jan 26, 2021 12:25 pm**

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

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.

Posted: **Fri Feb 26, 2021 5:30 pm**

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

Cheers,

OSDev.org

hbreak does not work in gdb for a KVM guest

hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest

Re: hbreak does not work in gdb for a KVM guest