[LLVMdev] built-in longjmp and setjmp

[Akira Hatanaka]

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
> 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 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 generated by arm-darwin is acceptable, does it mean
> that you can freely move code that accesses a global variable above the call
> to setjmp?
> >
> > On Wed, Apr 27, 2011 at 2:03 PM, Jim Grosbach <grosbach at apple.com>
> wrote:
> > 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 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 previous email)?
> > >
> > > # line 39 - 47
> > >  ldr r1, LCPI1_1
> > >  ldr r2, [r1]
> > >  add r2, r2, #1
> > >  str r2, [r1]
> > >  add r4, pc, #8              @ eh_setjmp begin
> > >  str r4, [r0, #4]
> > >  mov r0, #0
> > >  add pc, pc, #0
> > >  mov r0, #1                  @ eh_setjmp end
> > >
> > >  ...
> > > LCPI1_1:
> > >   .long _gi2
> > >   .align  2
> > >
> > >
> > > On Wed, Apr 27, 2011 at 11:38 AM, Akira Hatanaka <ahatanak at gmail.com>
> wrote:
> > > 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 setjmp6.arm.ll -o setjmp6.arm.s
> > >
> > >
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > void *buf[20];
> > >
> > > int gi2 = 0;
> > >
> > >
> > > void __attribute__ ((noinline)) sub2 (void)
> > > {
> > >   __builtin_longjmp (buf, 1);
> > >
> > > }
> > >
> > > int
> > > main (int argc, char **argv)
> > > {
> > >   int n = atoi (argv[1]);
> > >   int r = __builtin_setjmp (buf);
> > >   ++gi2;
> > >
> > >   if (r)
> > >     {
> > >       printf ("setjmp %d\n", n + gi2);
> > >       return 0;
> > >     }
> > >
> > >   sub2 ();
> > >
> > >   return 0;
> > > }
> > >
> > >
> > > On Wed, Apr 13, 2011 at 10:05 AM, Jakob Stoklund Olesen <
> stoklund at 2pi.dk> wrote:
> > >
> > > 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;
> > > >     }
> > >
> > >
> > > /jakob
> > >
> > >
> > >
> > > <f.s>_______________________________________________
> > > 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/20110427/cac54c2e/attachment.html>