On Tue Jul 1 00:54:29 2025 +0000, Paul Gofman wrote:
Which exact unwinding do you mean, PE side Wine implemented (probably?), or something Unix side? rbp has no special meaning on x64, it is just one of non-volatile register. If it is not properly restored during PE unwind, it is probably the same as many other non-volatile registers as well (e. g, r12, xmm6)? Then all of those should probably be restored. I'd guess that yeah, call_user_mode_callback() might be the only place for it because there is no context saved in callback_stack_layout (unlike exception_stack_layout or apc_stack_layout). But you probably don't need to pass any of those registers to restore to call_user_mode_callback() and can just use those from frame (including FP state probably).
PE side.
The rbp is important because unwind op code `UWOP_SET_FPREG` uses it to restore the rsp.
The problems is that the wrong rbp got saved on to the stack frame.
When something like this happens:
some user mode functions (1) -> syscall -> kernel mode -> `call_user_mode_callback` -> callback -> more user mode functions
the callback function (`KiUserCallbackDispatcher`) saves whatever rbp it gets onto the stack. if this rbp differs from what it was at point (1), unwind breaks.