[cfe-dev] [LLVMdev] Clarifying the state of setjmp/longjmp support in LLVM and Clang

Jim Grosbach grosbach at apple.com
Wed May 8 15:15:47 PDT 2013

Hi Eli,

You pretty much have it right already, honestly.

builtin setjmp and longjmp are for Darwin SjLj exception handling on ARM. That’s the llvm.eh.sjlj.* intrinsics.

On May 8, 2013, at 2:25 PM, Eli Bendersky <eliben at google.com> wrote:

> I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing.
> Clang.
> Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly):
> * __builtin_setjmp: gets lowered to calling the llvm.sjlj.setjmp intrinsic
> * setjmp() library call does not appear to be handled specially, although a no-longer-comment in a test I removed in r181468 said: 
> "__builtin_longjmp/setjmp should get transformed into llvm.setjmp/longjmp 
>  just like explicit setjmp/longjmp calls are."
> On my Ubuntu machine, the call actually gets transcibed to calling _setjmp, but that may be due to compiler settings in system library headers.
> LLVM supports two flavors of setjmp/longjmp intrinsics: llvm.{set|long}jmp and llvm.eh.sjlj.{set|long}jmp
> The latter is documented in http://llvm.org/docs/ExceptionHandling.html and has some tests for it. The former is not documented anywhere and has no tests. The former is handled by lowering the intrinsic call to calling the actual library function in SelectionDAGBuilder.cpp
> --------------
> My questions are:
> * First of all, is this a correct summary?

Sounds right, yeah.

> * Why the (defunct) comment in a Clang test? Was clang lowering setjmp library calls to intrinsics at some point?

Not sure. It probably just got missed during a cleanup/refactoring at some point.

> * Are the llvm.setjmp and llvm.longjmp intrinsics still officially supported? Being absent in the language reference and especially tests can lead one to believe they are deprecated.

If they’re not deprecated, they probably should be.

> Thanks in advance,
> Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130508/5d0f2887/attachment.html>

More information about the cfe-dev mailing list