Date: Mon, 21 Jan 2013 19:24:09 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: "toolchain@freebsd.org" <toolchain@FreeBSD.org>, Hongli Lai <hongli@phusion.nl>, Pedro Giffuni <pfg@FreeBSD.org> Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121172409.GJ2522@kib.kiev.ua> In-Reply-To: <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Mon, Jan 21, 2013 at 05:09:25PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: > > > On Mon, Jan 21, 2013 at 04:12:00PM +0000, David Chisnall wrote: > >> On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > >> > >>> Yes, quite possible. AFAIR, the 'catch' code compares the exception classes > >>> by the shared object ownership. It might get confused due to filter providing > >>> some symbols. > >>> > >>> But I did not investigated the cause for real. > >> > >> The issue appears to be that the libstdc++ exports a few functions[1] that libsupc++ exports, but with different symbol versions. Unfortunately, these are things that set handlers that are then called from libsupc++ / libcxxrt when, for example, an exception specification violation is encountered. > >> > >> I'm not sure what the solution is here. Is there some version-script-foo that we can do to say 'filter this symbol with this version as if it were this one with this version'? We ideally want to keep them with the current version in libcxxrt / libsupc++, but not introduce linker errors. > >> > >> David > >> > >> [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected() > > > > Can you prepare the minimal isolated test case which demostrates the > > behaviour ? A plan would be to ask somebody to run the test on the linux. > > I think we must be bug-to-bug compatible with glibc in regard to the > > filters quirks. > > I'm not sure what you want the test case to demonstrate. I have a reduced form of the exception test case, but it only fails for us because of the symbol versioning issue. Moving the relevant symbols into the same version in our libsupc++ and libcxxrt as in libstdc++ fixes it (and is probably the right thing to do. On closer inspection both already expose new and delete in this symbol version namespace, so it's fine to add a few more). > > > Gnu filters work only on the whole object scope. Solaris linkers do > > have per-symbol filtering, but Solaris does not implement per-symbol > > versioning, on the other hand. > > If you want a simple test case for the filter behaviour, the recipe is: > > Symbol X in filter with version A > Symbol X in filtee with version B > Symbol Y in program uses symbol X > > Program sees version A, filtee sees version B. So can you provide self-contained test.tgz with Makefile and neccessary .c files which demonstrate exactly the behaviour you see ? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/Xm5AAoJEJDCuSvBvK1BZVMQAJZLhX886Vsh4ZhQ5CNa6Qya jYSW3YUlrSe+Xjw2+WffpwmPBMIa+1M2laLOVXb3L/IUIXVT5llXvSgRpOlyOWKV xMPOBJIGgwY6XMB/vgnuM5v7LTQkJ9LZXWz2gYjX+hwSg7uY1jgtUYHp0McI/wNK f/237EbbernBMwPS2EbhMrdXmeKkid/2loXJJPrQ1AEfX2ioqt/knjp2b2hVHayf lTFGSoJqly1c7om7Nfu5LDwmOB9+xpW0SYcWupzbv8BP+lqhs80tjMCo5N6l2Oqw FRONUFcIfXeP9tcLgzSKM9RBQXDF4UW/DKhVRh1gvxQ6BvRSkqZvh3XVLZkGQCy8 Sp3U/8nEqkVHJOBnz5Cx1n1hMKYRC9cbNsGCXJ9WGK3sKMAfsEyXtscrjwOPORyn oDMMS74YgPerMhIo5YRW56unAfEpw4QdZB5POJ7aU/3I5RilxYlnML6vUx5fQfZq xDRxFujBKwMhG8WPnLwBg6XKI7qNLFvnUbZFVj7rlH43BRXiezS0RVaj/LoIrDZk i30OL//FHMOVV7aOyE34KqiTdLNDtO1fyNgzHGWnZyksahhJWtvJZA90kqZyuivO lVilIa5rm63fgt+yBE+Mo7xcqadNffwzODJugDyAwb7sQtH8UOTmmjcdJFIsJ763 1eftPJ4Z5VIHIsl3XUTF =9qXn -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130121172409.GJ2522>