[cxx-abi-dev] ABI modification for exception propagation
Dennis Handly
dhandly at cup.hp.com
Wed May 28 04:15:57 UTC 2008
>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?
>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.
>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.
>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?
>From: David Vandevoorde <daveed at edg.com>
>What sort of failure modes would we expect. Could the
>"__cxa_exception by reference" be made to look like std::bad_exception
>to an old runtime support library?
Would that be acceptable?
>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.
More information about the cxx-abi-dev
mailing list