GDB debugging with edition 3?

[ChocolateLoverRaj]

Has anyone successfully done debugging a UEFI OS following edition 3? I can set a breakpoint (with b main.rs:125) but after running c it never stops at the breakpoint.

[tsatke]

What's your current setup? How do you connect to qemu? How do you load the symbols in gdb?

[ChocolateLoverRaj]

Here is the code:

use std::{
    env,
    process::{self, Command},
};

fn main() {
    println!("{}", env!("UEFI_IMAGE"));
    println!("{}", env!("CARGO_BIN_FILE_KERNEL"));
    let mut qemu = Command::new("qemu-system-x86_64");
    // To increase memory
    // qemu.arg("-m");
    // qemu.arg("4G");
    // To show serial port in terminal
    // qemu.arg("-serial").arg("stdio");
    // To enable debugging and pause
    // qemu.arg("-s").arg("-S");
    qemu.arg("-drive");
    qemu.arg(format!("format=raw,file={}", env!("UEFI_IMAGE")));
    qemu.arg("-bios").arg(ovmf_prebuilt::ovmf_pure_efi());
    env::args().skip(1).for_each(|arg| {
        qemu.arg(arg);
    });
    let exit_status = qemu.status().unwrap();
    process::exit(exit_status.code().unwrap_or(-1));
}

Then I run it:

   Compiling code-runner v0.1.0 (/home/rajas/Documents/code-runner)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.58s
     Running `target/debug/qemu-uefi -s -S -serial stdio`
/home/rajas/Documents/code-runner/target/debug/build/code-runner-dd2095bbe9ff3898/out/code-runner-uefi.img
/home/rajas/Documents/code-runner/target/x86_64-unknown-none/debug/deps/artifact/kernel-81a57ac52bb2866d/bin/kernel-81a57ac52bb2866d

Then I run gdb /home/rajas/Documents/code-runner/target/x86_64-unknown-none/debug/deps/artifact/kernel-81a57ac52bb2866d/bin/kernel-81a57ac52bb2866d -ex "target remote localhost:1234":

GNU gdb (GDB) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/rajas/Documents/code-runner/target/x86_64-unknown-none/debug/deps/artifact/kernel-81a57ac52bb2866d/bin/kernel-81a57ac52bb2866d...
Remote debugging using localhost:1234
0x000000000000fff0 in ?? ()
(gdb) b main.rs:281
Breakpoint 1 at 0x43652: main.rs:281. (2 locations)
(gdb) c
Continuing.

It never reaches the breakpoint. Same thing with UEFI and BIOS.

[tsatke]

You have to tell gdb where to look for the symbols.

(this is simplified) Your bootloader doesn't load the kernel at 0x00. You're giving gdb your symbols file, and invoke b main.rs:281. This resolves to address 0x43652 in the symbols file. gdb (or QEMU) will now pause when the instruction pointer hits 0x43652.

The problem is, that your kernel is not loaded at 0x00, but at 0xffff_fff8_0000_0000 (or somewhere in that area). You have to tell gdb to always add that offset to the addresses for symbol resolution.

For gdb, there is --offset or -o (I believe), for lldb there is --slide. See also my code and this StackOverflow post.

Edit

The bootloader loads the kernel wherever it pleases. The bootloader that's used in the tutorial doesn't load the kernel at 0x00.

If you're using limine and a static executable (as opposed to a PIE, which is used in this tutorial), you don't have to specify an offset.

See this

[tsatke]

Also, to build upon this (because it was a pain for me to figure this all out when I did it):

• You can use "-g" in your .cargo/config.toml [rustflags] to get symbols in case you're not finding some of them.
• In the same place, you can use "-C", "force-frame-pointers=yes", which will display full backtraces in interrupt handlers (otherwise they'll be truncated, at least for me with lldb)

See this page for more cool stuff that you can configure there.

[ChocolateLoverRaj]

Setting the offset worked (0x8000000000 in my case) for setting breakpoints with b main.rs:129.

But doing b kernel_main still doesn't work, even with -g. I even copied your config.toml from devos:

[unstable]
# enable the unstable artifact-dependencies feature, see
# https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dependencies
bindeps = true

[target.x86_64-unknown-none]
rustflags = [
    "-C",
    "link-arg=-z",
    "-C",
    "link-arg=nostart-stop-gc",
    "-C",
    "force-frame-pointers=yes",
    "-g",
]

and after rebuilding gdb still can't find kernel_main, but it can find _ZN6kernel11kernel_main17h156da7ea239c32b6E (which I got from nm):

(gdb) file /home/rajas/Documents/code-runner/target/x86_64-unknown-none/debug/deps/artifact/kernel-81a57ac52bb2866d/bin/kernel-81a57ac52bb2866d -o 0x8000000000
Reading symbols from /home/rajas/Documents/code-runner/target/x86_64-unknown-none/debug/deps/artifact/kernel-81a57ac52bb2866d/bin/kernel-81a57ac52bb2866d...
(gdb) b kernel_main
Function "kernel_main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b _ZN6kernel11kernel_main17h156da7ea239c32b6E
Breakpoint 1 at 0x8000041875: file kernel/src/main.rs, line 130.
(gdb)

[bjorn3]

You probably need to break on kernel::kernel_main.

[tsatke]

Add a #[unsafe(no_mangle)] to the function you want to break on. Not nice of course, I prefer breaking on filename and line number for that reason. I have experimented writing lldb scripts to handle the mangling, but to no avail.

Did Bjorns suggestion work for you?

[bjorn3]

AFAIK the UEFI firmware relocates EFI executables. The debugger is not aware of this however and would look at the original location (if the GDB you use even supports the PE executable format in the first place) You may have better luck with using BIOS.

[ChocolateLoverRaj]

It isn't working with BIOS either.

[bjorn3]

Maybe try hbreak instead of break. That uses hardware watchpoints which tend to be more reliable in VMs as they don't depend on modifying the executable code itself (which the bootloader would overwrite again)

[ChocolateLoverRaj]

Even with hbreak the execution never stopped.