| ... | @@ -1647,21 +1647,6 @@ fn handleSegfaultPosix(sig: posix.SIG, info: *const posix.siginfo_t, ctx_ptr: ?* | ... | @@ -1647,21 +1647,6 @@ fn handleSegfaultPosix(sig: posix.SIG, info: *const posix.siginfo_t, ctx_ptr: ?* |
| 1647 | }; | 1647 | }; |
| 1648 | const opt_cpu_context: ?cpu_context.Native = cpu_context.fromPosixSignalContext(ctx_ptr); | 1648 | const opt_cpu_context: ?cpu_context.Native = cpu_context.fromPosixSignalContext(ctx_ptr); |
| 1649 | | 1649 | |
| 1650 | if (native_arch.isSPARC()) { | | |
| 1651 | // It's unclear to me whether this is a QEMU bug or also real kernel behavior, but in the | | |
| 1652 | // former, I observed that the most recent register window wasn't getting spilled on the | | |
| 1653 | // stack as expected when a signal arrived. A `flushw` from the signal handler does not | | |
| 1654 | // appear to be sufficient either. On the other hand, when doing a synchronous stack trace | | |
| 1655 | // and using `flushw`, this all appears to work as expected. So, *probably* a QEMU bug, but | | |
| 1656 | // someone with real SPARC hardware should verify. | | |
| 1657 | // | | |
| 1658 | // In any case, the register save area exists specifically so that register windows can be | | |
| 1659 | // spilled asynchronously. This means that it should be perfectly fine for us to manually do | | |
| 1660 | // so here. | | |
| 1661 | const ctx = opt_cpu_context.?; | | |
| 1662 | @as(*[16]usize, @ptrFromInt(ctx.o[6] + StackIterator.stack_bias)).* = ctx.l ++ ctx.i; | | |
| 1663 | } | | |
| 1664 | | | |
| 1665 | handleSegfault(addr, name, if (opt_cpu_context) |*ctx| ctx else null); | 1650 | handleSegfault(addr, name, if (opt_cpu_context) |*ctx| ctx else null); |
| 1666 | } | 1651 | } |
| 1667 | | 1652 | |
Alex Rønne Petersen <alex@alexrp.com> 2026-08-28 14:06:49+02:00
Signed by SSH key SHA256:7B/LJ7bpR1eX8aCXSr4mtd5M45VMPKcx9zY8e95b5QM
lib