From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 16:54:33 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 E3C82FD2; Mon, 21 Jan 2013 16:54:33 +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 85886ED4; Mon, 21 Jan 2013 16:54:33 +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 r0LGsSSB069709; Mon, 21 Jan 2013 18:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0LGsSSB069709 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0LGsSv0069708; Mon, 21 Jan 2013 18:54:28 +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 18:54:28 +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: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J1ldk4ymECC/Y9sn" Content-Disposition: inline In-Reply-To: <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@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 16:54:34 -0000 --J1ldk4ymECC/Y9sn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 cla= sses > > by the shared object ownership. It might get confused due to filter pro= viding > > 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] tha= t libsupc++ exports, but with different symbol versions. Unfortunately, th= ese are things that set handlers that are then called from libsupc++ / libc= xxrt 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() 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. 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. --J1ldk4ymECC/Y9sn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/XLDAAoJEJDCuSvBvK1BLSgP/ilxbTO+0sUU6miJCWTkt65Y K3DGVuMKEIC4sQeMPvt5+K3WXdGYmEyEpNAFuU3CQqAvJO+4cwPpflKFlMqzkfOB G7B2IIAtM+eyQqEL1oh6patFr3+IrF2V3n7dWYCKrXygNdbCfYxVA1Z1L00cEiD3 zPqK6fBVJT5MBx8Ny6tX3bB9ehrW24FeYCgBjI0+FvFonAPHWOUu3NA1szkMpWr7 mE6bDZhQ+eZOs/sEmS0ys9U9pVK5by+U/faLFJr0D2j1y+zxYCw/d5hedg3JgFT2 rRKEK5S13Aqwe2za/pUNVlQDoKdNRkhGQr5awN61GIl+XxSkF7yVkO15j7mL2n62 NAEaqFq4GftHWZhDhHkcn1hWAKfGfCSV9+N/USCs1HCNADWg9iGiYTjynnofd8SE 3RmiJ5aDJY5nI+R2qUCjXZuMXTlgW+iJO0ibOoyvdBsST7l6wJ+xy9kjet5k03TC d/se2Qz7/4NEI+yDI/fy29lbKYF6Cjhgs+RLThzDay8Faj0nSSDJkjTT8NVHk/20 cxgzk5bfJ/VzYYarG6A4Jm2fhSxGfQ9cPCX66h797b8bzYUJC+LohajL4WszcLt1 NCC/OWS/mn4w0u3WaCScYbWcs1KM4zKIdFlUMGefYxQucHXO8Lqb5A6GNNSsSAnE YJQHX4e+80j8IR/914dC =8VBT -----END PGP SIGNATURE----- --J1ldk4ymECC/Y9sn--