On Jul 18, 2014, at 9:52 AM, Josh Haberman <jhaber...@gmail.com> wrote: > >> The only option when targeting C is to use >> setjmp / longjmp, but that is going to be pretty inefficient. > > Why do you think of setjmp/longjmp as inefficient? If you use the > _setjmp/_longjmp variants that don't fiddle with the signal mask, they > seem pretty efficient to me. > > The bigger problem with setjmp/longjmp to me is that they don't let > you clean up variables sitting on the stack, as Rust language > semantics do I believe? > > I can think of a way to do this portably, but it costs two extra > pointers every time you declare any stack variables. Basically you > could, every time you declare local variables, make them part of a > struct that has a pointer to the enclosing local var struct, and a > pointer to an unwind function. Then when a task fails, traverse this > list of frames and run the unwind function for each one before calling > longjmp(). > > It's wasteful of stack space (since this is basically duplicating > unwind info that exists at the system level, like in .eh_frame), but > it is portable.
This is more along the lines of what I meant. The 32-bit ARM Darwin ABI actually uses this form of exception handling, and LLVM has some support for it. Unlike DWARF unwinding you incur a cost for every cleanup that you register, so it can be quite expensive. Having had to debug issues with it in the past in LLVM, I'm not sure I would really trust the codegen to be correct. Cameron _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
