[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