From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 09:25:38 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B38C011C; Mon, 21 Jan 2013 09:25:38 +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 6B9DCA4F; Mon, 21 Jan 2013 09:25:38 +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 r0L9PYof055065 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 09:25:35 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=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121044912.GE2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 09:25:36 +0000 Message-Id: References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@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 09:25:38 -0000 --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=koi8-r 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. >=20 > But I did not investigated the cause for real. I'm investigating this. It seems that the issue still appears when = using libcxxrt instead of libsupc++ with libstdc++ (the test cases work = fine with libc++ and libcxxrt), so it is likely some symbol confusion in = libstdc++. My guess would be that it's using pointer comparison for the exception = type info names and these are somehow different as a result of the = filter library mode. I'll investigate further later today. David --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09 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/QmQAAoJEKx65DEEsqIdOdAQAK5Omjp1N0VChYAtQDwokS+R ReXZnr9WBuwr/gdS2Ws7fT3sWboiQdt04RQupaD+fatxMmT8dY2t1vrj+e+vL9OO 1Ou2dbZIOIgvYJOJKDndnTw+3UeJjCgmaONs8LDjkJtjPYx+9k5raEg1HhNEa9GF cEkj51p1pEtTWBNFKHIwDqpqACbVunR8qwEIgoiI2ZOwDzXKVTNq4VM9u2eRK4xj H3x+/fIKoQHHeQhvno5DYWhWM1NAwL8zhfn3BSHWO6/RkycyHHiV0wb5McYYJ5qq cXSV29SNhfGeLj9ctj/OkbkVPFkYG5GMVN1uaIIKL5+/bCWCJ+eQ7KBvh2oBYdYx fa/8pbeQClLfcdqa/ryongF2fjzUF+FdvSYhtX3aUy7b8rdGKRW3T1VrRdJ9ccO9 Nx60AFys0279ECPPaez2izau6z13yzA3Qg/U7zBoBzTqE+yxyD/NIJ84JV48tP3s zRYIKpsgOQROBbB/0QwK2lKLz3cRacm93WOpTTeA3Uv7O0PUj22gg2wXbEMEmfNG CL2ci78amLyxzKHltl/V4E9x/p3n7Cu8msXT5H74+uoYFU73gM5yDWDshpkkEHMU itS3JwV3hn1KH1vauWi9l7CG81tREAMSHO7Ubh4PCA56QoTF3xqNyMYasrlLI+sp 0KY2KfHdKb1v498FlDdB =WVnM -----END PGP SIGNATURE----- --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09--