[llvm-commits] [llvm-gcc-4.2] r102148 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Duncan Sands]

Hi Bill,

> A fix for a nasty bug (<rdar://problem/7885482>). Here's what's happening:
>
> Consider this pseudo-ObjC code:
>
>        // locking using some "lock" variable
>        @try {
>          // ...
>        } @catch (...) {
>          // ...
>          @throw;
>        } @finally {
>          // unlocking using the "lock" variable
>        }
>
> The "lock" variable has live intervals from the top of the function through the
> @try block and in the @finally block. On 32-bit x86, it doesn't have a live
> interval in the @catch block. This is because in 32-bit mode Objective-C uses
> setjmp/longjmp for exception handling and not the invoke/DWARF method.  The
> @throw is implemented as an "objc_exception_throw" call marked with
> NORETURN. The upshot is that if the "lock" variable is placed into a stack slot,
> there won't be an indication that the "lock" can be used after the
> "objc_exception_throw" executes. With the invoke/DWARF method, the unwind edge
> of the invoke points to the @finally block, so the "lock" variable will have a
> live interval leading to there.
>
> The solution is to have the "objc_exception_throw" behave in a similar manner to
> the invoke/DWARF method. That is remove the "NORETURN" attribute, allowing it to
> have an edge from the call to the @finally block.

I didn't understand your explanation.  Can you please try again using smaller
words!  Alternatively, add a testcase and I will work it out for myself.

> +    if (!TARGET_64BIT&&  Callee->getName() == "objc_exception_throw")
> +      cast<Function>(Callee)->removeFnAttr(Attribute::NoReturn);

Wouldn't this be better off in the objc front-end?  Also, if I understood your
description right (which I don't think I did), can't this kind of thing go
wrong for any code that make use of setjmp/longjmp?

Ciao,

Duncan.