You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the generated unwinding information only restores registers. This issue proposes to make it possible to also run cleanup actions like running destructors during unwinding.
Benefit
This is necessary to support unwinding after a panic in rustc_codegen_cranelift.
Implementation
Add a new invoke terminator that is similar to the call instruction, but has an additional cleanup edge. This cleanup edge will be ignored when emitting actual machine instructions, but it will take part in the regalloc. Next add a way to mark a block as "landing pad". Only "landing pad" blocks can be used as cleanup edge of an invoke terminator. At the start of a "cleanup" block all values are stored either on stack or in any of the registers restored by the system unwinder. The "landing pad" block can also take several arguments. Those will be the values stored in the registers that are allowed for arguments to the landing pad received from the personality function. After codegen the location of every "landing pad" block will be stored in a variable. This will allow the embedder to generate the appropriate LSDA (language specific data area) to reference from the unwinding table.
Alternatives
It is basically impossible to implement cleanup during unwinding without Cranelift support.
Reacted by Léo Gaspard, Acshi Haggenmiller, Virgiel, Vitalii Kryvenko, Afonso Bordado, Jakub Beránek, Dmitry Tilyupo, David Hamill, Daniel, Felipe S. S. Schneider and 12 more
Reacted by Baye Dieng, Putta Khunchalee, stefnotch, Orvar, Cherry, pianocomposer321, Jakub Beránek, Timo, Marc-Stefan Cassola, D4vyCode and 8 more
Reacted by Filipp Samoilov, Félix Fischer, Finchie, Orvar, Cherry, Jean Mertz, pianocomposer321, Dennis Krasnov, Lucas Pluvinage, Jakub Beránek and 22 more
Reacted by Niclas Overby Ⓝ, Max “Goldstein” Siling, David Eichmann, Dennis Krasnov, Suraj, Hasan Mohsin, Orión, bbb651 🇮🇱, Frank Elsinga, Yerkebulan Tulibergenov and 13 more
Cleaning up old issues and I believe this is covered now by the exceptions support we landed recently (#10510). Thanks all (and thanks bjorn3 for the experimental work that helped us develop our current design).
Right, this issue was specifically about Cranelift exceptions, @whitequark -- I will hopefully get time to do the Wasmtime side soon (next few months-ish)...
Activity
bjorn3 commentedon Jul 3, 2021
Original pdf no longer exists. See https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html instead.
bayedieng commentedon Feb 26, 2023
Could this issue be solved independently using the aforementioned solution in the OP's comment or would #3427 be needed to be resolved first?
bjorn3 commentedon Feb 26, 2023
I'm working on this.
overby-me commentedon Jun 26, 2024
@bjorn3 Any PR or branch where it is possible to follow progress?
bjorn3 commentedon Jun 26, 2024
https://github.com/bjorn3/wasmtime/tree/bsc-unwinding-simple-invoke3 is the latest version I have. I will rebase it and work on upstreaming when I finish my thesis about it.
cfallin commentedon Apr 23, 2025
Cleaning up old issues and I believe this is covered now by the exceptions support we landed recently (#10510). Thanks all (and thanks bjorn3 for the experimental work that helped us develop our current design).
whitequark commentedon Apr 24, 2025
Oh, does wasmtime support exceptions now? This is incredibly exciting, is there anything I can read on that?
bjorn3 commentedon Apr 24, 2025
This isn't implemented on the Wasmtime side yet.
Edit: #2049, #3427 and #10252 are still open.
cfallin commentedon Apr 24, 2025
Right, this issue was specifically about Cranelift exceptions, @whitequark -- I will hopefully get time to do the Wasmtime side soon (next few months-ish)...
fitzgen commentedon Apr 24, 2025
And if you'd like to learn more, here is the RFC: bytecodealliance/rfcs#36
whitequark commentedon Apr 24, 2025
Thanks all!