-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing s390x with RUST_BACKTRACE=1 in QEMU crashes #9719
Comments
Good news is I can reproduce natively, so it's not a qemu issue. The segfault happens in MD_FALLBACK_FRAME_STATE_FOR in libgcc, because of an invalid PC. This typically indicates some problem with unwind info in a lower frame. And indeed GDB also isn't able to unwind fully. I'll need to look where this comes from. |
This is a regression introduced with the tail-call ABI. If we have incoming tail-call stack arguments, the DWARF rule to unwind the caller's SP is incorrect. I'm working on a fix. |
On s390x, the unwound SP is always at current CFA - 160. Therefore, the default rule used on most other platforms (which sets the unwound SP to the current CFA) is incorrect, so we need to provide an explicit DWARF CFI rule to unwind SP. With the platform ABI, the caller's SP is always stored in the register save area like other call-saved GPRs, so we can simply use a normal DW_CFA_offset rule. However, with the new tail-call ABI, the value saved in that slot is incorrect - it is not corrected for the incoming tail-call stack arguments that will have been removed as the tail call returns. To fix this without introducing unnecessary run-time overhead, we can simply use a DW_CFA_val_offset rule that will set the unwound SP to CFA - 160, which is always correct. However, the current UnwindInst abstraction does not allow any way to generate this DWARF CFI instruction. Therefore, we introduce a new UnwindInst::RegStackOffset rule for this purpose. Fixes: bytecodealliance#9719
The above PR fixes the issue for me. |
On s390x, the unwound SP is always at current CFA - 160. Therefore, the default rule used on most other platforms (which sets the unwound SP to the current CFA) is incorrect, so we need to provide an explicit DWARF CFI rule to unwind SP. With the platform ABI, the caller's SP is always stored in the register save area like other call-saved GPRs, so we can simply use a normal DW_CFA_offset rule. However, with the new tail-call ABI, the value saved in that slot is incorrect - it is not corrected for the incoming tail-call stack arguments that will have been removed as the tail call returns. To fix this without introducing unnecessary run-time overhead, we can simply use a DW_CFA_val_offset rule that will set the unwound SP to CFA - 160, which is always correct. However, the current UnwindInst abstraction does not allow any way to generate this DWARF CFI instruction. Therefore, we introduce a new UnwindInst::RegStackOffset rule for this purpose. Fixes: #9719
In landing #9702 I was wrestling with a s390x-specific failure on CI. The problem seems to stem from
RUST_BACKTRACE=1
and usingstd::backtrace
which an updated version ofanyhow
uses. This code is now all landed onmain
so the current main branch of Wasmtime fails with:@uweigand would you be able to help take a closer look at this? I'm not sure if this is a Wasmtime/jit code issue (maybe unwind info?) or something else in rustc perhaps
The text was updated successfully, but these errors were encountered: