Panic backtrace on Arm64 Windows is truncated

[dpaoliello]

When running the tests\ui\runtime\backtrace-debuginfo.rs test again aarch64-pc-windows-msvc, the test fails because the backtrace has been truncated:

thread 'main' panicked at C:\repos\rust\tests\ui\runtime\backtrace-debuginfo.rs:114:9:
explicit panic
stack backtrace:
   0:     0x7ff91fe0d544 - std::backtrace_rs::backtrace::win64::trace
                               at C:\repos\rust\library\backtrace\src\backtrace\win64.rs:85
   1:     0x7ff91fe0d544 - std::backtrace_rs::backtrace::trace_unsynchronized<std::sys::backtrace::_print_fmt::closure_env$1>
                               at C:\repos\rust\library\backtrace\src\backtrace\mod.rs:66
   2:     0x7ff91fde5510 - std::sys::backtrace::_print_fmt
                               at C:\repos\rust\library\std\src\sys\backtrace.rs:66
   3:     0x7ff91fde5510 - std::sys::backtrace::impl$0::print::impl$0::fmt
                               at C:\repos\rust\library\std\src\sys\backtrace.rs:39
   4:     0x7ff91fe2264c - core::fmt::write
                               at C:\repos\rust\library\core\src\fmt\mod.rs:1481
   5:     0x7ff91fddbeac - std::io::default_write_fmt<std::sys::stdio::windows::Stderr>
                               at C:\repos\rust\library\std\src\io\mod.rs:639
   6:     0x7ff91fdcf11c - std::io::Write::write_fmt<std::sys::stdio::windows::Stderr>
                               at C:\repos\rust\library\std\src\io\mod.rs:1914
   7:     0x7ff91fde540c - std::sys::backtrace::BacktraceLock::print
                               at C:\repos\rust\library\std\src\sys\backtrace.rs:42
   8:     0x7ff91fe04364 - std::panicking::default_hook::closure$0
                               at C:\repos\rust\library\std\src\panicking.rs:300
   9:     0x7ff91fe04184 - std::panicking::default_hook
                               at C:\repos\rust\library\std\src\panicking.rs:327
  10:     0x7ff91fe04b5c - std::panicking::rust_panic_with_hook
                               at C:\repos\rust\library\std\src\panicking.rs:833
  11:     0x7ff91fde5bf4 - std::panicking::begin_panic::closure$0<ref$<str$> >
                               at C:\repos\rust\library\std\src\panicking.rs:770

Digging into this further, the issue appears to be that the call to RtlVirtualUnwind stops after unwinding after std::panicking::begin_panic::closure$0<ref$<str$> > because the function reported by RtlLookupFunctionEntry is incorrect.

RtlLookupFunctionEntry seems to be getting confused as std::panicking::begin_panic::closure$0<ref$<str$> > is a non-returning function where its last instruction is to branch to another non-returning function. Thus, the return address reported from rust_panic_with_hook is actually after the end of std::panicking::begin_panic::closure$0<ref$<str$> >:

0:000> u 0x7ff91fde5bf0
std_b6e0767fb633a355!std::panicking::begin_panic::closure$0<ref$<str$> >+0x2c [C:\repos\rust\library\std\src\panicking.rs @ 770]:
00007ff9`1fde5bf0 94007ba1 bl          std_b6e0767fb633a355!std::panicking::rust_panic_with_hook (00007ff9`1fe04a74)
std_b6e0767fb633a355!std::sys::pal::windows::pipe::anon_pipe [C:\repos\rust\library\std\src\sys\pal\windows\pipe.rs @ 59]:
00007ff`91fde5bf0 d10583ff sub         sp,sp,#0x160

We might need to, somehow, get LLVM to add some padding for this case.

[bjorn3]

Is rust responsible for calling RtlLookupFunctionEntry? If so can we subtract 1 from the return address before doing the lookup? That is what we do for looking up the function name with DWARF: https://github.com/rust-lang/backtrace-rs/blob/903c10db222c24b3e0fd085dfb0523abff192c5c/src/symbolize/mod.rs#L123-L147

[ChrisDenton]

Is rust responsible for calling RtlLookupFunctionEntry?

Yes.

[dpaoliello]

I'll do some experiments with this later, for now I'm documenting it as I try to stand up the Arm64 Windows runner.

@rustbot claim