On 7 January 2014 15:04, Alon Zakai <[email protected]> wrote: > On Tue, Jan 7, 2014 at 11:22 AM, Mark Seaborn <[email protected]>wrote: > >> On 7 January 2014 02:31, Mark Callow <[email protected]> wrote: >> >>> On 2014/01/07 10:35, Alon Zakai wrote: >>> >>> Not all functionality is complete yet in the new compiler, see the list >>> of limitations in that link - stuff like setjmp and C++ exceptions are the >>> main missing things. We'll implement those soon I hope, but I'm sending >>> this email out to see which of the missing features is most important, so I >>> know how to prioritize. >>> >>> Priorities for me would be >>> >>> >>> 1. Linking of asm.js shared modules >>> 2. C++ exceptions >>> >>> @Alon: I haven't looked very closely at how Emscripten implements C++ >> exceptions, such as how it encodes landingpad clauses in Javascript. You >> might find PNaCl's ExceptionInfoWriter.cpp useful for Emscripten. It's >> currently used by PNaClSjLjEH.cpp, and it encodes the landingpad clauses >> into three tables, which are interpreted by libsupc++ or libcxxabi. From >> skimming the source, I get the impression that Emscripten is doing >> something similar. >> > > I noticed that, and wasn't sure what it does. How does it relate to LLVM's > LowerInvoke pass? That also aims to lower invoke into setjmp AFAICT? >
Well, the broader picture is that upstream LLVM has support for SJLJ exception handling, but that support is partly implemented in the backend. lib/CodeGen/SjLjEHPrepare.cpp is an IR pass which lowers invokes to use setjmp(), but it doesn't do the lowering of the exception info (the catch/filter/cleanup clauses in the landingpad) -- it leaves that to the backend, which lowers landingpads to the .gcc_except_table format. For PNaCl, we didn't want landingpads' exception info or the .gcc_except_table format to be part of PNaCl's stable ABI, because they're too complex (see https://code.google.com/p/nativeclient/issues/detail?id=3118 for some background). This means we have to do the lowering of landingpads to data tables as an IR-to-IR pass. However, there's nothing in upstream LLVM for doing that lowering as an IR-to-IR pass, so I implemented that in ExceptionInfoWriter.cpp. I haven't actually tried using upstream LLVM's SJLJ EH support, but I assume it works because it's used on iOS (see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-October/032656.html). However, I don't think lib/Transforms/Utils/LowerInvoke.cpp is part of LLVM's currently working SJLJ EH support. I think it is left over from earlier SJLJ EH support. I'm not sure it does a useful transformation. But it definitely doesn't lower landingpads' exception info, so it's not what we want for PNaCl. > Currently emscripten lowers invoke into JS try-catch stuff, and uses > libcxxabi to do the c++ type stuff, which does sound similar to what you > mention there. Still no definite plan how to do it in the new compiler. > Yes, you've told me about the try/catch part before. What I didn't know was how you're lowering the landingpad clauses. I've had a closer look now. It looks like landingpadHandler() in jsifier.js will take a landingpad like this: %lp = landingpad ... personality ... catch i8* @exception_type1 catch i8* @exception_type2 and convert it to: __cxa_find_matching_catch(-1, -1, exception_type1, exception_type2) where __cxa_find_matching_catch() is implemented in library.js and uses "arguments" to read the variable-arguments list. So it look like this doesn't handle "filter" clauses (for C++ exception specifications). Presumably you ignore the "cleanup" clause, but it's OK to treat every landingpad as if it has a "cleanup" clause. (In order for the IR to be inliner-friendly, Clang generates landingpad blocks which can handle being entered even if the exception being thrown didn't match a "catch" clause.) So you're encoding the landingpad's exception info as a list of arguments in Javascript. We could have done something similar in PNaCl, but I figured it was a bit more efficient to generate a read-only table in the data segment (as C++ exception handling normally does) and pass a reference to that. Cheers, Mark -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
