From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:09:34 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CDA43F3; Mon, 21 Jan 2013 17:09:34 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8B9F71; Mon, 21 Jan 2013 17:09:33 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0LH9UcT056570 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 17:09:31 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121165427.GG2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 17:09:25 +0000 Message-Id: <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> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:09:34 -0000 --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--