[cxx-abi-dev] Details missing for EH 2.4.1 Overview of Throw Processing

Dennis Handly dhandly at cup.hp.com
Wed Dec 21 03:27:45 UTC 2011


>From: John McCall <rjmccall at apple.com>
>> I'm saying that __cxa_end_catch is the code that destructs the
>> full-expression, if you elide the copy construction.

>This conversation would be substantially easier if you looked
>up terms like "full-expression" that you don't understand.

>Note that the actual exception object is not formally a temporary.

Thanks for the details.
My confusion was not in "full-expression" but thinking the exception operand
was a temporary.

>Regardless of whether copy elision occurs, __cxa_end_catch has
>the potential to throw, because it has the responsibility to destroy the
>actual exception object ('exn').
>which, as I mentioned, is not a temporary.

And here I mistakenly thought the Standard didn't allow the throw because
this was a temporary.

>But only some calls to __cxa_end_catch occur during unwinding:  only if
>you throw out of a catch clause.  If control falls out of a catch clause,
>and the destructor for the caught exception object throws an
>exception, that new exception just starts propagating.

That's the one I was confused about.

>in the catch for a 'void *', you know that __cxa_end_catch
>will not throw, because that catch type cannot catch any objects
>with destructors.
John.

Ah, so at compile time, you could statically remove the landing pad on
__cxa_end_catch based on that.

I found out my problem.  The landing pad for __cxa_end_catch was set to
__cxa_end_catch.  ;-)
I.e. the call wasn't treated special and for that one, don't add that call.



More information about the cxx-abi-dev mailing list