From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:24:19 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 4A326894; Mon, 21 Jan 2013 17:24:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6C2AC; Mon, 21 Jan 2013 17:24:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0LHOArs072913; Mon, 21 Jan 2013 19:24:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0LHOArs072913 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0LHO9BT072912; Mon, 21 Jan 2013 19:24:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 19:24:09 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121172409.GJ2522@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> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aRzsUE0Mp86t8N62" Content-Disposition: inline In-Reply-To: <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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:24:19 -0000 --aRzsUE0Mp86t8N62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 05:09:25PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: >=20 > > 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 c= lasses > >>> by the shared object ownership. It might get confused due to filter p= roviding > >>> 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++ / l= ibcxxrt when, for example, an exception specification violation is encounte= red. > >>=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 we= re this one with this version'? We ideally want to keep them with the curr= ent 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 linu= x. > > I think we must be bug-to-bug compatible with glibc in regard to the > > filters quirks. >=20 > I'm not sure what you want the test case to demonstrate. I have a reduce= d 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 th= e right thing to do. On closer inspection both already expose new and dele= te in this symbol version namespace, so it's fine to add a few more). >=20 > > 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. >=20 > If you want a simple test case for the filter behaviour, the recipe is: >=20 > Symbol X in filter with version A > Symbol X in filtee with version B > Symbol Y in program uses symbol X >=20 > Program sees version A, filtee sees version B. So can you provide self-contained test.tgz with Makefile and neccessary =2Ec files which demonstrate exactly the behaviour you see ? --aRzsUE0Mp86t8N62 Content-Type: application/pgp-signature -----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----- --aRzsUE0Mp86t8N62--