similar to: [LLVMdev] Clarifying the state of setjmp/longjmp support in LLVM and Clang

The builtins are for internal compiler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not

Okay. I understand builtin functions do not have to behave exactly the same way as standard library functions. What I wanted to know is what should the code generated by llvm (clang + llc) look like (I am working on the Mips back-end now). I guess there should be a behavior users expect to see who are using __builtin_setjmp/longjmp even they aren't the same as library functions. If the code

Okay. Are you saying that you shouldn't use __builtin functions in general in your program or just __builtin_setjmp/longjmp? Also, are there any warnings issued by either clang or llvm if they are used in your program? On Wed, Apr 27, 2011 at 3:55 PM, Jim Grosbach <grosbach at apple.com> wrote: > The builtins are for internal compiler use in the context of SjLj exception >

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

ARM/Darwin implements them. I'm not aware of any others. That said, they are designed for internal use by the compiler for exception handling. Calling them directly like this is very much not recommended. Using the system library setjmp()/longjmp() functions is preferred. -Jim On Apr 12, 2011, at 1:56 PM, Akira Hatanaka wrote: > Does the X86 backend (or any other backend) correctly

What would be the best way to convert built-in setjmp and longjmp tp library calls? Should it be implemented in clang or in backends? On Tue, Apr 12, 2011 at 2:38 PM, Jim Grosbach <grosbach at apple.com> wrote: > ARM/Darwin implements them. I'm not aware of any others. > > That said, they are designed for internal use by the compiler for exception > handling. Calling them

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote: > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer > <khalid.alwazeer at gmail.com> wrote: >> Hi, >> >> I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable >> is inserted, which is fine. The problem is that in the backend before >> calling longjmp, some register was spilled to a

That code should do it, but I realized you only detect setjmp functions by name. My code is calling "__sigsetjmp" not "segsetjmp". You only support these functions: static const char *ReturnsTwiceFns[] = { "_setjmp", "setjmp", "sigsetjmp", "setjmp_syscall", "savectx", "qsetjmp",

I declared gi2 as "volatile" and I think gi2 is still incremented once. Here is a snippet of the code. Line 39 - 42 increments gi2. According to the standard, shouldn't ++gi2 be executed twice regardless of whether gi2 is volatile or not? Isn't the missing chain from EH_SJLJ_SETJMP node to load/store nodes that access gi2 causing this problem (please see attached file in my

On Apr 13, 2011, at 9:51 AM, Akira Hatanaka wrote: > int > main (int argc, char** argv) > { > int n = atoi(argv[1]), r; > > if ((r = setjmp (buf))) > { > printf("n = %d\n", n); > return 0; > } Non-volatile local variables are not preserved by setjmp(), so this program can print whatever it wants. /jakob

There is no C standard to follow for these builtins. You are expecting them to behave as if they were the standard library calls. They are not equivalent and the naming similarity is an unfortunate historical artifact. Use the standard library functions instead. -Jim On Apr 27, 2011, at 1:22 PM, Akira Hatanaka wrote: > I declared gi2 as "volatile" and I think gi2 is still

On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote: > Recap: we use setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing

On Apr 27, 2011, at 4:08 PM, Joerg Sonnenberger wrote: > On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: >> The builtins are for internal compiler use in the context of SjLj >> exception handling. Any other use, including any direct calls of the >> builtins in user code, are a bad idea with no guaranteed behaviour. >> That they're exposed at all is,

I have another basic question about setjmp/longjmp. When I compile and run the following program, is it expected that global variable gi2 will be incremented twice? It seems that the code generated with clang and llc increments it only once (line 37-43 of attached file). $ clang setjmp6.c -o setjmp6.arm.ll -emit-llvm -O3 -S -ccc-host-triple arm-unknown-darwin -ccc-clang-archs arm $ llc

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

Does the X86 backend (or any other backend) correctly implement support for __builtin_setjmp and __builtin_longjmp? I don't get the correct result when I compile and run the following code with clang. # clang foo.c -O3; ./a.out #include <stdio.h> void *buf[20]; void __attribute__((noinline)) foo (void) { __builtin_longjmp (buf, 1); } int main (int argc, char** argv) { if

Hi, I would like to build an x86 executable consisting of a number of subsystems (mostly legacy C code). One subsystem will be compiled to native code using llvm. It calls, and is called by, the other subsystems, many of which have to be compiled using gcc because they use small amounts of inline assembly. All of the subsystems catch and throw errors to one another using setjmp/longjmp. When

Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use

On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com> wrote: > Hi, > > I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable > is inserted, which is fine. The problem is that in the backend before > calling longjmp, some register was spilled to a stack location which is live > across the jmp. I mean, it will be live after