Implement emitting Windows unwind information for fastcall functions. #1155
Conversation
|
I've marked this as a draft so I can get early feedback of the changes. I'm still working on consuming this change from Wasmtime so that Windows can walk/unwind across JIT frames. I'll make this PR ready when those changes have been properly tested. |
|
Woah! This is really cool! I think some of the stack layout information you're collecting in How does Windows unwind information handle functions with multiple epilogues, if at all? The Upside, if you can phrase this as information built on top of |
|
Epilogues on Windows x64 ABI are strictly defined, so the OS can tell if it's in an epilogue by disassembling forward a few bytes from the frame IP. Functions are allowed to have multiple epilogues. For unwind, if it detects that the frame IP is in the epilogue, it will simulate the remaining execution of the epilogue to unwind the frame; thus the OS needs no description of epilogues in the unwind information. I did look at #679 and I think there's work there I can piggy back off of, although it does seem to be DWARF-tailored. For Windows x64 (we'll need an Windows ARM implementation eventually, but unwind information on ARM is quite different), we just need information about the prologues for unwind; at least until such time where a Cranelift function can have an exception handler. Still, I would like #679 to go in first and then we can figure out what makes sense to merge this in with the |
|
I've tested these changes with corresponding changes to Wasmtime and was able to get successful stack walks (by Visual Studio's debugger) and unwinds through JIT frames on Windows. I think we may want to focus on getting #679 in first and then I can rebase this on top of those changes and see what makes sense to merge in with those changes. |
peterhuene
force-pushed
the
x64-unwind-info
branch
from
f1c13c1 to
6659ac9
Compare
peterhuene
force-pushed
the
x64-unwind-info
branch
2 times, most recently
from
15a843f to
63461ed
Compare
This commit implements emitting Windows unwind information for x64 fastcall calling convention functions. The unwind information can be used to construct a Windows function table at runtime for JIT'd code, enabling stack walking and unwinding by the operating system.
This commit addresses code review feedback: * Remove unnecessary unsafe code. * Emit the unwind information always as little endian. * Fix comments. A dependency from cranelift-codegen to the byteorder crate was added. The byteorder crate is a no-dependencies crate with a reasonable abstraction for writing binary data for a specific endianness.
* Disable default features for the `byteorder` crate. * Add a comment regarding the Windows ABI unwind code numerical values. * Panic if we encounter a Windows function with a prologue greater than 256 bytes in size.
peterhuene
force-pushed
the
x64-unwind-info
branch
from
5a41555 to
96d5307
Compare
|
Rather than waiting on #679 to merge first (which hasn't had much progress in the past week), I think we may want to get this merged (pending approval) to unblock getting the Wasm test suites passing on Windows for Wasmtime. The Windows unwind information is intentionally isolated from the rest of Cranelift code generation and I can easily refactor this, as needed, once the tracking frame layout changes PR is merged. |
This PR implements emitting Windows unwind information for x64 fastcall
calling convention functions.
The unwind information can be used to construct a Windows function table at
runtime for JIT'd code, enabling stack walking and unwinding by the operating
system.