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

[Sebastian Redl <sebastian.redl@xxxxxxxxxxxxxx>]

Dennis Handly wrote:
> > From: Sebastian Redl <sebastian.redl@xxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxx>
> > 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