Generating full backtraces for an emulated toy OS

Evan Davis cptroot@gmail.com
Fri Mar 24 16:41:00 GMT 2017


Hello,

I'm currently writing a toy OS project, and I am currently trying to
get my backtraces to work. Currently my backtraces break when the
kernel is called into at memory location 0x8000006b00, and I'm trying
to figure out why.

Here are the relevant stack frames that I've captured using gdb:

run_kernel (after push %rbp and mov %rsp, %rbp):
0x676ea30: 0x000000000676efe0 0x0000000006679dee
0x676ea40: 0xafafafafafafafaf 0x0000008000006b00
0x676ea50: 0x0000008000063000

kernel_main (after push %rbp and mov %rsp, %rbp):
0x676e9b0: 0x000000000676ea30 0x0000000006679eb3
0x676e9c0: 0x000000000676ea00 0x0000008000006b00
0x676e9d0: 0x0000000007f21f18

Backtrace at the start of run_kernel:
#0  0x0000000006679e34 in loader::run_kernel (
    entry=0x6677ab1 <spin::mutex::{{impl}}::drop<serial::SerialWriter>+49>,
    system_table=0x0, page_table=...)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:265
#1  0x0000000006679dee in loader::new_stack (elf_file=..., page_table=...,
    system_table=0x7f21f18)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:261
#2  0x0000000006678fef in loader::rust_main (image_handle=...,
    system_table=0x1)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:203
#3  0x0000000000000000 in ?? ()

Relevant instructions before and after the jump into the kernel:
before:
(gdb) x/5i $pc
=> 0x6679ea9 <loader::run_kernel+121>: mov    -0x20(%rbp),%rsi
   0x6679ead <loader::run_kernel+125>: mov    -0x18(%rbp),%rdx
   0x6679eb1 <loader::run_kernel+129>: callq  *%rax
   0x6679eb3 <_ZN6loader10run_kernel17h9de89e77bf6ead15E+131>:
    nopw   %cs:0x0(%rax,%rax,1)
   0x6679ebd <_ZN6loader10run_kernel17h9de89e77bf6ead15E+141>: nopl   (%rax)

after:
(gdb) x/5i $pc
=> 0x8000006b00: push   %rbp
   0x8000006b01: mov    %rsp,%rbp
   0x8000006b04: sub    $0x12f0,%rsp
   0x8000006b0b: mov    %rdi,-0xed8(%rbp)
   0x8000006b12: mov    %rsi,-0xec8(%rbp)

Backtrace at 0x8000006b01 (kernel_main):
#0  0x0000008000006b01 in ?? ()
#1  0x000000000676ea30 in ?? ()
#2  0x0000000006679eb3 in loader::run_kernel (entry=0x8000006b00,
    system_table=0x7f21f18, page_table=...)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:272
#3  0x0000000006679dee in loader::new_stack (elf_file=..., page_table=...,
    system_table=0x7f21f18)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:261
#4  0x0000000006678fef in loader::rust_main (image_handle=...,
    system_table=0x6f)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:203
#5  0x0000000000000000 in ?? ()

Backtrace at 0x8000006b04 (kernel_main):
(gdb) bt
#0  0x0000008000006b04 in ?? ()
#1  0x000000000676ea30 in ?? ()
#2  0x0000000006679eb3 in loader::run_kernel (
    entry=0x667583d
<core::mem::replace<frame_allocator::FrameAllocator>+61>,
system_table=0x10000000676ea30, page_table=...)
    at /media/sf_CS_81/rusty_pintos/uefi_booter/loader/src/lib.rs:272
Backtrace stopped: frame did not save the PC

Backtrace at 0x8000006b0b (kernel_main):
#0  0x0000008000006b0b in ?? ()
#1  0x0000000000000000 in ?? ()


Can anyone help me figure out why GDB isn't finding the backtrace
after the jump to the kernel? The stack hasn't changed location, so
I'm confused why it's having difficulty.

-Evan Davis



More information about the Gdb mailing list