On Fri, Jul 18, 2014 at 12:35 AM, Cameron Zwarich <zwar...@mozilla.com> wrote: > The biggest problem would be probably be handling stack > unwinding (IIRC the LLVM C backend never tried to handle > this either).
Interesting, I can see what that would be a challenge. > 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. In any case, it sounds like no one is working on this, so it's probably unlikely to happen unless someone takes it up. Thanks for the info! Josh _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
