bitcode exception handling (LLVM 3.4/Pure 0.60)

Issue #25 resolved
Simon Beaumont
created an issue

I have a question about loaded bit code and exception handing.

I have a c++ class that is wrapped in the usual extern "C" way and has an exception handler that catches any c++ exceptions -- it logs an error and returns a NULL pointer; this is kind of conventional C wrapping of c++. If I build a shared library and load an execute the extern function in pure this all works as expected. However if I emit bitcode and load this into pure then the functions all work -- but in this case if an exception is thrown then the "landing pad" handlers are never called and an abort is called and the interpreter of course terminates.

Now I'm not at all clear whether this is a problem with how llvm generates code or how the pure runtime handles exceptions in llvm execution engine. This is tricky business so I am hoping you can steer me in the right direction.

I am using clang 3.4svn on OS 10.9.

Comments (8)

  1. Albert Graef

    I should also note that Pure itself doesn't use LLVM's exception handling intrinsics in any way, it uses setjmp/longjmp to implement its exception handling. In theory, this shouldn't interfere with LLVM's exception handling. So my guess is that LLVM's JIT requires some kind of special initialization to make EH intrinsics in the bitcode work (or maybe they don't even work with the old JIT at all?).

    Edit: Well, the intrinsics which raise a C++ exception do seem to work according to your description, it's just that the landing pads don't get set up, so that control is transferred to the Pure runtime instead, which simply bails out with an unhandled C++ exception.

  2. Simon Beaumont reporter

    I was thinking just that; if I examine the disassembled bitcode all the landing pad code is in there - but as you say hooking this up to the llvm execution engine probably requires some magic. I'll dig around in the LLVM documentation and see if/how this can be made to work. In my case I can probably avoid exceptions or stick with the dynamic library solution. I'll take a look at LLVM execution engine and see if there are any clues in there. I suppose what would be nice is if any "plugin" code raises an exception this would be mapped to a pure exception so it could be handled in pure. But realistically how sandboxed can dynamically loaded code be?

  3. Simon Beaumont reporter

    I think you guessed it - From the LLVM 3.3 release note:

    MCJIT now supports exception handling. Support for it in the old jit will be removed in the 3.4 release.
    

    As good as their word -- from the 3.4 release note:

    Support for exception handling has been removed from the old JIT. Use MCJIT if you need EH support.
    
  4. Albert Graef

    Ok, thanks for clarifying this. So that means that you'll have to work around this for now. We can keep the issue open as a reminder. Migration to the MCJIT is on my TODO list anyway, but it's a bit tricky in Pure's case, so this may still take some time.

  5. Simon Beaumont reporter

    Good - I can work around this no problem just using the shared lib approach -- I'll take a look at the MCJIT architecture as I am interested in this -- seems to be a major change in terms of modules/compilation units.

  6. Log in to comment