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

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.

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?
* Why the (defunct) comment in a Clang test? Was clang lowering setjmp
library calls to intrinsics 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.

Thanks in advance,
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/e4557c0d/attachment.html>

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.
> 
> 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/llvm-dev/attachments/20130508/5d0f2887/attachment.html>