[LLVMdev] Do the LLVM SJLJ intrinsics interact with C++ exception handling and execute C++ cleanup actions?

Christian Schafmeister chris.schaf at verizon.net
Tue May 27 14:43:08 PDT 2014


Thank you!

I was envisioning all sorts of wonderful uses for the SJLJ intrinsics to implement non-local exits for the Common Lisp CATCH/THROW, BLOCK/RETURN-FROM and TAGBODY/GO special operators that would work in a way that was compatible with C++.    Currently I’m using C++ exception handling and it works fine but I have been under the misapprehension from reading http://llvm.org/docs/ExceptionHandling.html#setjmp-longjmp-exception-handling that SJLJ intrinsics were a parallel mechanism to C++ exception handling that offered different trade-offs in run-time cost/overhead.

I see now that SJLJ is a more primitive exception handling mechanism for a subset 32-bit iOS.

Best,

.Chris.



On May 27, 2014, at 4:51 PM, Jim Grosbach <grosbach at apple.com> wrote:

> The intrinsics are completely distinct from the standard library functions. The names are historical legacy from GCC. They’re used for 32-bit iOS exception handling. I’m not aware of them being tested or supported in any other context.
> 
> -Jim
> 
> On May 27, 2014, at 1:26 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:
> 
>> 
>> 
>> Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions?
>> 
>> I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp.
>> 
>> I’m wondering if the LLVM intrinsics behave differently from setjmp/longjmp.
>> 
>> Best,
>> 
>> .Chris.
>> 
>> Christian Schafmeister
>> Professor, Chemistry Department
>> Temple University
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 





More information about the llvm-dev mailing list