[cxx-abi-dev] ABI modification for exception propagation

[Sebastian Redl]

Dennis Handly wrote:
>> From: Sebastian Redl <sebastian.redl at getdesigned.at>
>> I experimentally implemented N2197 "Exception Propagation" in GCC and 
>> came to the conclusion that the current exception handling ABI 
>> specification is insufficient.
>>     
>
> Any reason we don't reject N2197 out of hand then?
>   
Exception propagation is very important. C++ got away with it so far 
most because, IMO, threading already had an unnatural feel in C++. Now 
that it has become part of the language, not being able to transfer 
exceptions would be a very sore point.
Also, the API is good and minimal. I don't think we'd be able to find a 
better alternative within reasonable time.
>> It describes a model where exceptions are bound to a single thread and
>> cannot be copied.
>>     
>
> Yes, for HP-UX, each thread has a TLS state.
>   
In GCC, the __cxa_eh_globals struct is thread-local. Is there anything 
else in HP-UX that's also thread-local?
>> From: Mark Mitchell <mark at codesourcery.com>
>> It looks like your proposal is not backwards-compatible with the current 
>> ABI.  I think we should try very hard to avoid breaking compatibility. 
>>     
>
> The only reason to break it is if the C++0x requires a new incompatible
> C++ Standard Library.
>   
I've done my best to avoid breaking the ABI this time around.
>> From: Mark Mitchell <mark at codesourcery.com>
>> Is the issue that current_exception may need additional information in 
>> order to locate the copy constructor for the thrown object.
>>     
>
> Any way we can say that current_exception doesn't work if a copy constructor
> is needed?
>   
No. std::exception requires a copy constructor (to initialize the vptr, 
if nothing else). std::runtime_error needs it even more. We'd be 
rejecting the entire C++ exception hierarchy, and probably every other 
hierarchy too. In fact, because we'd have to transfer values somehow, 
we'd be bound to use memcpy, which would mean that current_exception 
could only be used when throwing PODs.
>> From: Sebastian Redl <sebastian.redl at getdesigned.at>
>> The reason is that in static links, there would be 
>> multiple emergency memory pools. An exception allocated in the emergency 
>> pool of one module and caught in a different module would then be 
>> incorrectly passed to free() for deletion
>>     
>
> You don't make the emergency memory pools global and exported so it is
> all the same one?
> We only hide symbols in our shared lib.
>   
In GCC's source, the emergency pool is unconditionally a static global. 
So no, they won't get merged. But I might have been wrong about the 
wrong one being used. Since destruction is done via 
_Unwind_DeleteException, the call goes back to the library that 
allocated the exception.

Sebastian