Stream: wasmtime

Topic: refactoring unwinding logic


view this post on Zulip Yury Delendik (Oct 13 2020 at 14:25):

@Peter Huene I started https://github.com/bytecodealliance/wasmtime/pull/2289 -- I'm trying to de-duplicate codegen's unwinding logic, and perhaps remove dependency of gimli crate (in the future?) Next step will be working on new backend. Did you have insights if this approach (UNWIND_INFO) will work for ARM64 ?

This PR: Creates common unwind info data structures (at cranelift::isa::unwind::input) Extracts common logic for SystemV and FastCall into "cranelift/codegen/src/isa/x86/unwind.rs" Moves...

view this post on Zulip Peter Huene (Oct 13 2020 at 18:18):

I'll look this over and let you know. I'm not as familiar with Window's ARM64 ABI and the pdata/xdata is quite a bit different (stack-manipulating functions can even be described without having xdata entries provided they follow specific canonical forms and don't have exception handlers).

view this post on Zulip Peter Huene (Oct 13 2020 at 20:56):

I put some comments up on the PR. I spent the last hour or two pouring over the Windows ARM64 ABI docs to understand how it differs in describing unwind information from x64. I don't see any inherent problems in the refactoring that would interfere with ARM64 on Windows. My concern is primarily over having to look at every instruction in the function on Windows; for x64 we only ever need to look at the entry block instructions and with ARM64 it's likely to be same provided Cranelift only emits epilogues that have a 1:1 reverse instruction for each prologue instruction.

view this post on Zulip Yury Delendik (Oct 13 2020 at 20:57):

Yeah, I was wondering about performance too. I'll see if it can be addressed somehow.


Last updated: Dec 23 2024 at 13:07 UTC