[rust-dev] compiling Rust to C?

Cameron Zwarich zwarich at mozilla.com
Fri Jul 18 10:14:22 PDT 2014

On Jul 18, 2014, at 9:52 AM, Josh Haberman <jhaberman at 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.


More information about the Rust-dev mailing list