Date: Mon, 21 Jan 2013 17:09:25 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> In-Reply-To: <20130121165427.GG2522@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >>=20 >>> 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. >>>=20 >>> But I did not investigated the cause for real. >>=20 >> 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. >>=20 >> 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. =20 >>=20 >> David >>=20 >> [1] std::set_new_handler(), std::set_terminate(), = std::set_unexpected() >=20 > 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. David= --Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/XZFAAoJEKx65DEEsqIdxZkP/0dIchz8vF2/6o6m/IKfjmyF RbbpG0t7ZmEyPjjcIiDbklYemgoxDVJEAO5tLwpzCC/sTBOHeNQwmlXOTySU8lSq Yde7JS+r0rxJkLnYvsxEp7blsdTNqTWxkR2EJpb6JBo++Op488liPtudvgaUanhy xzI00pfbkq0qxEgsvSQKj0SB5gb0PUqGQPW1xqU0CXYWF0jS9H0LIozdVmTIRi7b KUz2VsF/xjMBxpHdqISETdNYSGvbPdoWNQ6e5mlx4R17pv5sBV1zzBDVMDiMwd8v bo4LlvYDmtLEGE9OIXAhw25+VV2FbY/Blau5pgvmq4J+1oIhDnunQ2wZ2x3FBAfR LA+xSPdGfPpo3DqC7A7sRUkKWZ9PqMVNU1oE0cPdsRGnCi7xqlb9OWVnVJ0eiD0D WMFEWOM8nLiCbWNZpqKiVlaI/yaf+xzHxH3BROHGSAXIW45IXHvKtFXOU1pl0+4M MIUyQjvjGWf2wek/QAQ6YgWzWtqEI1sVM6j0bgN+ejzmpzoHeqz+bzkHhefZC6y8 +TxAoev42RETUU8knN1XyCn3KjfybdjXkLoZgcPWeU/ih+IANFGe0ykWCc3VEWpp WiueKfqK5WuiE2oDV5y9dKe1SnFGaKXF8zJ2zOhTq0yJVo6sRu72aVEcX6VHsj+3 RNb9enL8uD03DvHy7DTr =1T3L -----END PGP SIGNATURE----- --Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C83B09F-5504-4848-8EB8-877305684254>