On Jan 24, 2012, at 4:28 PM, Howard Hinnant wrote: > On Jan 24, 2012, at 3:59 PM, Sebastian Redl wrote: > >> >> On 24.01.2012, at 19:15, Howard Hinnant wrote: >> >>> Author: hhinnant >>> Date: Tue Jan 24 12:15:20 2012 >>> New Revision: 148827 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=148827&view=rev >>> Log: >>> Move kOurExceptionClass and kOurDependentExceptionClass from source to >>> header so that they can be used in multiple sources. This is a private >>> header, these constants are not publicly exposed. >> >> Why don't we reuse GCC's exception class? We already call our personality >> routine the same. Don't we want to be link-compatible with gcc-compiled >> stuff? >> >> Sebastian > > I think that's a possibility. On __APPLE__ we will never be in a situation > where gcc's runtime will be in play at the same time as libc++abi (so that > possibility has not been designed for). > > So this is more of a question for those interested in libc++abi running on > non-Apple platforms. Is this a scenario people want to tackle? To work it > will take some considerable design. I can think of two ways to go: > > 1. Try to mimic gcc's runtime in every way, and somehow make it ok for > either run time to catch an exception thrown by the other. > > 2. Have distinct exception_class ID's, to give each run time a chance to > recognize that they are dealing with a foreign exception and take suitable > action. > > I have not given the problem enough thought to have formed an opinion, and > probably won't until I complete the personality routine.
Getting back to a good question asked by Sebastian. A foreign exception is one that is caught by this library (maybe just temporarily to do a clenaup, maybe permanently), but was not thrown by this library. If an exception is not thrown by this library then __cxa_throw was never called for it, at least not this library's implementation of it. __cxa_throw, among other things, alters data in the thread-local __cxa_eh_globals data structure: it increments the number of uncaught exceptions. This is later decremented in __cxa_begin_catch. And the thread-local __cxa_eh_globals data structure is also allocated and provided by this library. Even if another library provides a thread-local __cxa_eh_globals data structure, it is not going to be the same one that this library provides. Because of this, I've come to the conclusion that if two Itanium libraries are active at the same time within an application, they should treat each other's exceptions as foreign. This will mean sometimes an exception is unexpectedly caught or not caught. But trying to do anything else is just going to lead to more subtle bugs such as std::uncaught_exception() sporadically returning the wrong answer. Really two different libc++abi's active at the same time in the same application is just a recipe for disaster no matter what (as far as I can figure out). I'm about to make the detection of two C++ runtimes stronger: I'm going to call anything that doesn't have one of the exceptions we generate foreign, even if it is a C++ exception, even one with an __cxa_exception header. And I believe there's no way to be link-compatible with a GCC runtime by using the GCC vendor id. Doing so would hide, instead of more readily expose the fact that two C++ runtimes are active. I'm open to discussion on this point. And as I write this, libc++abi is not currently consistent with what I'm writing. But unless there are objections, I'm about to make it so. Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
