standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

Konstantin Belousov kostikbel at gmail.com
Mon Jan 21 16:54:34 UTC 2013


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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130121/24b707bc/attachment.sig>


More information about the freebsd-toolchain mailing list