[llvm-bugs] [Bug 34556] C++ std::exception is NULL when compiled as ObjC++, but C++ is OK

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34556

David Lobron <dlobron at akamai.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #14 from David Lobron <dlobron at akamai.com> ---
I got a very helpful reply from David at GNUstep:

"This test case works perfectly for me on FreeBSD, where clang defaults to
-fobjc-runtime=gnustep.  It segfaults if I add -fobjc-runtime=gcc.  This is
entirely expected, because the GCC ABI for exceptions is makes it impossible to
correctly interop with C++ (I spent a few weeks trying and it always fails for
at least some of the corner cases).  If you specify -fobjc-runtime=gnustep-1.8,
then it will work correctly.

When using the GNUstep ABI, Objective-C objects are thrown as Objective-C
exceptions, C++ objects are thrown as C++ exceptions.  The GNUstep ObjC++
personality function is used for catch and @catch blocks in ObjC++ code, the
ObjC personality function for @catch blocks in ObjC code, and the C++
personality function in C++ code.  The C++ and ObjC personality functions don’t
let you catch foreign exceptions (except for cleanups or with catch(…) in C++).
 The ObjC++ personality function checks whether the thrown exception is from
C++ or ObjC.  If it’s thrown from C++, it simply forwards it to the C++
personality function.  If it’s thrown from ObjC, then it wraps it in a C++
exception first, and provides some special C++ type_info structures that allow
the C++ personality function to deliver it to the correct block.  This allows
us to use a slightly more efficient code path for pure-ObjC exceptions.

The Apple implementation simply implements the ObjC exceptions as thin wrappers
around C++ exceptions, so ObjC exceptions are always thrown as C++ exceptions. 
This means that the Apple ObjC runtime has a hard dependency on their C++
runtime, even when not using ObjC++. This doesn’t matter too much for them,
because a bunch of their core frameworks are C++ or ObjC++, so there’s likely
not to be any code on macOS / iOS that uses ObjC but not C++.

Note: We have tests for all of these cases in the libobjc2 test suite.  There’s
also some logic to allow foreign exceptions to be automatically boxed as ObjC
objects."

So this does not appear to be an llvm/clang problem, but rather I was using the
wrong ABI.  I will resolve this CR as INVALID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171101/f7e6f8f1/attachment-0001.html>