Re: LuaJIT vs C++

[Mike Pall <mikelu-0803@...>]

Alexander Gladysh wrote:
> As you know, compiling Lua as C++ basically changes longjmp() in
> LUAI_THROW to throw; and setjmp() in LUAI_TRY to try {} catch() {}.
> This change is crucial as longjmp/setjmp basically do not call any
> destructors in C++ objects.

That's only part of the problem. The other issue is that throwing
a C++ error "across" a C++ -> Lua -> C++ call chain would leave
Lua in an inconsistent state.

> Now we're considering a switch to LuaJIT. Vanilla LuaJIT does not
> compile as C++.

This is untested, because it's not a supported configuration.
Sorry, I should have ripped out the option in luaconf.h.

> However, compiled LuaJIT crushes on errors (same when embedded in our app):

GCC uses DWARF2 exception handling for C++ exceptions. This
depends on accurate stack frame information for every function
(this is the .eh_frame section in ELF objects).

But LuaJIT is a JIT compiler and generates code at runtime. The
dynamically generated functions have no unwind info. The GCC
unwinder cannot cope with this and terminates the process if a
JIT-compiled frame is on the stack between the catching and the
throwing frame.

> Unfortunately, we currently do not have any resources to debug this
> issue. We also currently have no resources on adopting our existing
> bindings to plain C Lua. So this is a showstopper

Well, this is a matter of resources for me, too. I've already
researched how to pass the necessary info to the GCC unwinder at
runtime. Unfortunately, this is quite complicated and would take
a lot of time to implement. I'm not sure it's worth the effort to
add this to the LuaJIT 1.x branch.

So far, nobody asked for this functionality. It seems compiling
Lua or LuaJIT as C++ isn't a popular configuration. Enabling
GCC's exception handling causes considerable bloat in the
executables and catch(...) has it's own share of problems.

> We need LuaJIT to work successfully on following platforms:
> 
> 1. Production-grade
>    Linux x64 (compiled as 32-bit code). BTW, would it work at all as such?

This works fine. You need to compile all code (not just LuaJIT)
as 32 bit to be able to link it together and run it as a 32 bit
process.

> 2. Development-grade
>    Linux x32
>    Windows x32
>    Intel OS X

The mechanism on Linux and OS X is the same (both use GCC). But I
don't know whether catching C++ exceptions across JIT-compiled
frames works on Windows. I guess this depends on which exception
handling method is used (SEH may work, others probably not).

--Mike