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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. David [-- Attachment #2 --] -----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-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C83B09F-5504-4848-8EB8-877305684254>