Hello Cranelift community,
I'm currently engrossed in a project utilizing Cranelift Codegen, and I'm keen on obtaining technical details regarding the development status of the unwind mechanism, specifically in the context of panic recovery. Could someone shed light on the progress, challenges, and any pertinent updates related to unwinding in Cranelift, particularly with respect to handling panics? Or what is its status?
I'm specifically interested in understanding the technical intricacies and potential implications for my project. Your detailed insights will be immensely valuable in navigating the nuances of the unwind feature within Cranelift.
cc @bjorn3 -- they were working on extending Cranelift to support this
I've implemented this for my bachelor thesis already. I'm currently working on writing the thesis itself. Once I'm done with that, I'm going to attempt to upstream my implementation.
bjorn3 said:
I've implemented this for my bachelor thesis already. I'm currently working on writing the thesis itself. Once I'm done with that, I'm going to attempt to upstream my implementation.
Oh haha, in fact I was looking for some way to contact you in case you had an email or something like that on your github page to contact you, since I saw that you were developing that. Can I ask how that's all going? Would the implementation of exception handling be possible? What limitations would it have?
I'm using jit to make an interpreted language with exception handling and try/catch blocks, so if it's possible I'd like to know how much I could implement that.
My implementation is compatible with the exception mechanism used by C++ on Unix, but it is generic enough that you can also implement a custom exception abi in case you want to avoid using the system unwinder for whatever reason (be it performance, be it security)
in fact I was looking for some way to contact you in case you had an email or something like that on your github page to contact you
I'm most responsive on this zulip (provided you either dm me or directly ping me such that I get a notification) and on the rust lang zulip.
bjorn3 said:
My implementation is compatible with the exception mechanism used by C++ on Unix, but it is generic enough that you can also implement a custom exception abi in case you want to avoid using the system unwinder for whatever reason (be it performance, be it security)
Oh ok, that sounds really cool, sorry for the question but, do you have an estimated date when you think it will be implemented?
in fact I was looking for some way to contact you in case you had an email or something like that on your github page to contact you
I'm most responsive on this zulip (provided you either dm me or directly ping me such that I get a notification) and on the rust lang zulip.
Oh, okay, would you mind if I DM you more questions about this topic? So as not to perhaps sound too insistent labeling you.
@bjorn3, exciting to hear that progress is continuing on this front! I've been meaning to reach out to you to ask about it.
@Daniel Hillerström has also been investigating implementing the exceptions proposal for Wasmtime, and that obviously has overlap with the Cranelift bits.
This is a big enough change that it should really go through the RFC process. (We can't just accept a code dump PR for a feature of this magnitude.) Would love to collaborate on designs/ideas/plans/implementation between everyone here.
My understanding is that @Daniel Hillerström is starting to draft an RFC, would love to get your input into it from the start
I've been meaning to reach out to you to ask about it.
There is no integration with Wasmtime and I don't think I will be working on it. I did keep the security requirements of Wasmtime in mind though. It is just that after fighting with the Wasmtime internals for quite a while to try adding support for exception tags, I just couldn't figure out how to thread it through all the different layers. I didn't finish the wasm->clif-ir lowering either as it depended on getting exception tags working. I believe I did get most of the way with the runtime support code to throw and catch exceptions, but couldn't test this for the aforementioned reasons either.
This is a big enough change that it should really go through the RFC process.
I agree.
fitzgen (he/him) said:
My understanding is that Daniel Hillerström is starting to draft an RFC, would love to get your input into it from the start
Yes absolutely! I welcome any insights/opinions.
For rustc_codegen_cranelift (cg_clif) I need compatibility with C++ exceptions due to extern "C-unwind"
in rust allowing C++ exceptions to pass through Rust and vice versa. For Wasmtime depending on the system unwinder is probably not the best idea for security reasons. As such what I implemented is basically Cranelift using the standard abi for landingpads, but rather than directly emitting exception tables in the .gcc_except_table
format like GCC and LLVM do, Cranelift would emit the exact location of every call that can unwind (or to be precise the address directly after the call instruction, as that is where the call returns) as well as the location of every landingpad which could be unwound to from that call site. Then the user of Cranelift (cg_clif or wasmtime) would assemble the exception tables in whichever format it prefers. For cg_clif this would be .gcc_except_table
, but for wasmtime it would likely be a much simpler format tailored to wasm exceptions. Also for wasmtime once the tailcall calling convention is used (does wasmtime already use it?), the landingpad abi could be customized as preferred when using the tailcall calling convention.
Last updated: Nov 22 2024 at 17:03 UTC