Exception Personality Function

Clang Frontend
1

Hi,

I've been testing Objective-C++ with clang, in preparation to the 2.9 release. Most stuff works, but I noticed one strange thing. Any @try block in Objective-C++ calls fails with an exception specifier violation. It seems that this is caused by the C++ personality function being used in all Objective-C++ code (non-Darwin platforms), even though the exception tables are being initialised with unwind data for the Objective-C runtime exception model.

The correct fix would be to use the C++ exception personality function on the eh_selector call for try/catch statements and the Objective-C personality function for @try / @catch statements.

Unfortunately, it seems that the information about the source-language type of the catch handler is lost by the time we get to the code for picking the personality function. It only uses the language mode. I presume that it's too late to get this fixed in time for 2.9, but I'd like to get it fixed in trunk anyway. I can just add an Objective-C kind to the EHScope's kind, and then tweak the logic for using the selector, but it might be cleaner to specify the personality function in the code that generates the rest of the information for the unwind tables.

Thoughts? Comments? Suggestions?

David

2

The reason I don't preserve this kind of information is that it's extremely easy to come up with situations where you absolutely need a personality function that can correctly handle both C++ and Objective-C exception types, and since that function has to exist, we might as well use it for sanity in inlining†. The most obvious example of such code is that we actually permit Objective-C types to be caught by 'catch', at least on Darwin; but even if you forbid that, you can just nest try and @try blocks.

I looked into it and couldn't find such a personality function for GNUStep, so I picked what I hoped was the most correct solution. If you want to implement a short-term hack that makes us use the right personality for single-language catches and emit an error on mixed catches, that's fine, but ultimately you really need a mixed-language personality function.

(†) LLVM's inliner isn't actually sane about exceptions, but even the new design which solves most of those problems doesn't deal with mismatched personality functions in any reasonable way. The core problem is that you can only have one personality function per function.

John.