Indeed I am not that sure about how GNUstep currently handles exceptions but I am giving you ideas from some crash reports with symbols from an Apple system.
And the conclusion on toll-free bridging is about the latest Apple implementation. You should really get a Mac and poke around. Just for your information, what I poked around with is OS X 10.8.3 and iOS 6.1.3, both. With non-fragile ABI it is almost impossible to construct a C struct that can perfectly mirror Objective-C objects' memory layout, especially under some corner circumstances. Apple found that out, and moved lots of code from Foundation to CoreFoundation so that CoreFoundation types are now all defined in a fashion that is compatible with new ABI. Try breakpoint on some vital Objective-C runtime functions and methods and run some CoreFoundation code, and you will be surprised. Before you do that, make sure you have latest OS X and Xcode. 发自我的 iPad 在 2013-6-4，16:45，David Chisnall <[email protected]> 写道： > On 3 Jun 2013, at 23:45, Maxthon Chan <[email protected]> wrote: > >> 1) Apple's libobjc depend on LLVM's libc++abi (in Linux, it should be >> libsupc++). Not only Apple did that to allow proper Objective-C++, but also >> something more. >> When an Objective-C exception is triggered and not caught in Objective-C >> code, it will be raised as a C++ exception. This happens no matter if your >> code have C++ or not. Here is an crash log explaining this: (MobileDeuterium >> is the app I wrote. It have zero C++ in it.) > > Please try to actually pay attention to GNUstep at some point if you insist > on having opinions about it. > > libobjc2 correctly handles interoperability with C++ exceptions and interacts > with libsupc++ or libcxxrt (if you'd bothered to even compile it, you'd have > seen the check where it looks for this library) and will correctly allow > Objective-C++ code to catch Objective-C objects in C++ catch blocks (and > throw Objective-C objects in throw statements that can be caught with > @catch). Version 1.7 and clang 3.3 introduces a new exception ABI that makes > this significantly cleaner. The test suite contains a number of tests for > correct exception propagation. > > Oh, and you're wrong. The way Apple implements Objective-C exceptions is to > construct C++ type_info objects and just use the same personality function > for C++ and ObjC. It doesn't raise it as a C++ exception when 'not caught in > Objective-C code', it raises it as a C++ exception all of the time. > objc_exception_throw() in the Apple runtime is just a thin wrapper around > __cxa_throw(). > > And no, we don't want to copy their implementation because it has some ugly > corner cases (try catch (void*) sometime) that cause segfaults where the > GNUstep runtime does the right thing. Oh, and the Objective-C personality > function is simpler (and faster) than the C++ personality function, so only > going via C++ when we are actually using C++ saves us some overhead. > > Finally, do you honestly think that, after implementing both libobjc2 and > libcxxrt (the C++ ABI / runtime library used in FreeBSD, NetBSD, and soon > OpenBSD), not to mention the unwinding code for non-local returns in > LanguageKit, that I didn't know how exceptions work? > > The rest of your email is completely irrelevant to the exception handling > issue and is mostly wrong. How toll-free bridging works is well documented > in a number of places. If you want to understand it, try reading the docs > sometime. > > David > > -- > This email complies with ISO 3103 > _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
