panics when used from x86_64 interrupt handler

[m-mueller678]

I am calling _Unwind_Backtrace from within an x86_64 interrupt handler. When unwinding tries to proceed to the caller of the interrupt frame, it panics. I think it should do one of these two instead:

• continue unwinding into the code that was interrupted (not sure if possible)
• terminate the backtrace at the interrupt frame (maybe with an error)

The panic happens here in Frame::unwind:

new_ctx[*reg] = value;

with reg = gimli::common::Register (17)

  unwinding::unwinder::with_context::<unwinding::abi::UnwindReasonCode, unwinding::unwinder::_Unwind_Backtrace::{closure#0}>
  _Unwind_Backtrace
  __rustc::rust_begin_unwind
  <unwinding::unwinder::arch::x86_64::Context as core::ops::index::IndexMut<gimli::common::Register>>::index_mut
  <unwinding::unwinder::frame::Frame>::unwind
  unwinding::unwinder::_Unwind_Backtrace::{closure#0}
  unwinding::unwinder::with_context::delegate::<unwinding::abi::UnwindReasonCode, unwinding::unwinder::_Unwind_Backtrace::{closure#0}>

I do not know how unwind normally detects that it has reached the end of the stack. Do I need to place some special bytes there to mark it?

[nbdd0121]

Can you include dump of eh_frame about relevant code? You can use dwarfdump --print-eh-frame.

In general, for anything that involves assembly. You'll need to make sure you're emitting CFI informations correctly, which is out of scope of this project and equally applies to all possible unwinder that you're using.

[m-mueller678]

I am unsure which parts of dwarfdump are relevant, so here is everything dwarfdump.txt. I could not find either of the functions involved in interrupt handling in there. I have not heard of CFI before, I will read up on it. The interrupt handler is defined entirely in Rust:

extern "x86-interrupt" fn interrupt_handler(frame:InterruptStackFrame) -> (){
    interrupt_error(&frame,0,"breakpoint");
}
fn interrupt_error(frame: &InterruptStackFrame, code: u64, name: &str) -> ! {
    if INTERRUPT_ERROR_ONCE.swap(true, Ordering::Relaxed) {
        loop {
            core::hint::spin_loop();
        }
    }
    panic!(
        "\
        Interrupt: {name}\n\
        Stack frame: {frame:#?}\n\
        Error code: {code:?}\n"
    );
}
static INTERRUPT_ERROR_ONCE: AtomicBool = AtomicBool::new(false);

I have also included the ip values reported by unwind in the backtrace this time. The symbol and line information gets resolved via addr2line by a wrapper script, unwinding is not involved in that part. In the below, the first backtrace is printed by an intentional panic inside the interrupt handler. During uniwnding, unwind panics, which results in the second backtrace. The kernel is loaded at an offset of 0xa00000. The below ip values already have that offset subtracted, but I don't know if it might show up somewhere else. It looks like I was wrong about the point at which the panic occurs. It happens when entering the frame of the interrupt handler, not when advancing to the interrupted code.

Backtrace:
ip=0x2e6fd
  unwinding::unwinder::with_context::<unwinding::abi::UnwindReasonCode, unwinding::unwinder::_Unwind_Backtrace::{closure#0}>
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:43:39
ip=0x3424d
  _Unwind_Backtrace
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:430:2
ip=0x1fa03
  __rustc::rust_begin_unwind
            at /home/marcus/develop/exokernel/kernel/src/panic.rs:32:5
ip=0xd599
  core::hint::spin_loop
            at /home/marcus/.rustup/toolchains/nightly-2025-12-01-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/hint.rs:278:13
ip=0xd599
  nolla_kernel::arch::x86_64::interrupt::interrupt_error
            at /home/marcus/develop/exokernel/kernel/src/arch/x86_64/interrupt.rs:98:13
[PANIC] panicked at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/frame.rs:166:20:
not implemented

Backtrace:
ip=0x2e6fd
  unwinding::unwinder::with_context::<unwinding::abi::UnwindReasonCode, unwinding::unwinder::_Unwind_Backtrace::{closure#0}>
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:43:39
ip=0x3424d
  _Unwind_Backtrace
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:430:2
ip=0x1fa03
  __rustc::rust_begin_unwind
            at /home/marcus/develop/exokernel/kernel/src/panic.rs:32:5
ip=0x312d3
  <unwinding::unwinder::arch::x86_64::Context as core::ops::index::IndexMut<gimli::common::Register>>::index_mut
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/arch/x86_64.rs
ip=0x30cbd
  <unwinding::unwinder::frame::Frame>::unwind
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/frame.rs:166:20
ip=0x2f127
  unwinding::unwinder::_Unwind_Backtrace::{closure#0}
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:134:9
ip=0x2ec22
  unwinding::unwinder::with_context::delegate::<unwinding::abi::UnwindReasonCode, unwinding::unwinder::_Unwind_Backtrace::{closure#0}>
            at /home/marcus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.8/src/unwinder/mod.rs:34:21

Thank you for your help

[nbdd0121]

Ah, you're using x86-interrupt ABI. LLVM will generate unwind info that instructs backup of all registers, include XMM registers, which are not normally present in ordinary APIs.

Currently I do not plan to support backing up XMM registers, as (1) it is never used elsewhere (2) unwinding past interrupt handler is a niche use case.

If you simply re-implement your exception handler entry point with global_asm!() or naked_asm!() then unwinding would just work and stop before entering the exception handler.

[m-mueller678]

Would you mind changing this to return a FATAL_PHASE1_ERROR instead of panicking? I can prepare a PR if you want.

[nbdd0121]

Currently the code is written to assume that accessing register state cannot fail (e.g. _Unwind_GetGR). I am unsure what's the best way to introduce fail-able path here, but you're welcome to try and submit PR.