This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch-rfc] N2179: Exception Propagation in C++
- From: Sebastian Redl <sebastian dot redl at getdesigned dot at>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, mark at codesourcery dot com
- Date: Wed, 13 Aug 2008 19:11:31 +0200
- Subject: Re: [patch-rfc] N2179: Exception Propagation in C++
- References: <48809CE2.1030500@windmuehlgasse.getdesigned.at> <916852.1216396821012.JavaMail.oracle@acsmt304.oracle.com> <4880D637.3050702@windmuehlgasse.getdesigned.at> <15968502.1216403855404.JavaMail.oracle@acsmt303.oracle.com> <48848C5F.508@windmuehlgasse.getdesigned.at> <3563700.1216648012003.JavaMail.oracle@acsmt304.oracle.com> <488677FA.8000701@windmuehlgasse.getdesigned.at> <28873818.1216775411231.JavaMail.oracle@acsmt301.oracle.com> <48875A5C.6080903@windmuehlgasse.getdesigned.at> <21979991.1216833609323.JavaMail.oracle@acsmt305.oracle.com> <3825956.1217239012707.JavaMail.oracle@acsmt301.oracle.com> <27280529.1217501658903.JavaMail.oracle@acsmt305.oracle.com> <18968936.1218119581291.JavaMail.oracle@acsmt304.oracle.com> <48A1E2B1.1030505@getdesigned.at> <10084862.1218570265098.JavaMail.oracle@acsmt301.oracle.com> <48A2E4B9.5010905@getdesigned.at> <27611442.1218646939544.JavaMail.oracle@acsmt304.oracle.com>
Paolo Carlini wrote:
Before finally applying the patch, I'd like to ask you a final courtesy: I tried to catch up with the discussion which took place on the cxx-abi mailing list, and, as I feared, it quickly becomes rather technical... Could you please summarize the abi compatibility features of the current implementation? Essentially, I just want to make sure that binaries built vs the old library (headers) still works fine when relinked vs the new library .so. Also, that old binaries and binaries built with the new library and not using the new features can interoperate when linked to the new .so.
OK, it works like this: whether the new or the old exceptions are used
depends entirely on the linked library. The new library creates new
exceptions and can handle new exceptions, whereas the old library
creates old exceptions and can handle old exceptions. The differences
are not visible to user code, which means that for code not using the
new features it doesn't matter against which library it links.
Problems arise only if there are multiple conflicting versions of the
library in a loaded image, e.g. when an executable statically linked
against libsupc++ loads an .so that loads libstdc++ dynamically, and the
libstdc++ is new, *and* exceptions travel between the two parts. I
haven't tested the specific behaviour of this case, but from my
understanding of the code, there are two options:
1) New code creates exception, old code catches it. This should actually
work, unless the new exception was thrown with rethrow_exception(). In
that case, the exception would be treated as foreign and could be caught
with catch(...), but nothing else. If it's a normal exception, I don't
see anything going wrong.
2) Old code creates exception, new code catches it. This will work,
unless the new code tries to call current_exception(), which would lead
to an access violation or silent data corruption (the code would try to
increment a reference count that's not there).
So, nothing bad should happen even when mixing libraries, but I wouldn't
want to rely on that.
However, the interoperation of old code with the new library and vice
versa should be completely unproblematic.
Sebastian