[Bug libc/11610] _init/_fini do not have proper unwinding information

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=11610

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-10-28 00:47:27 UTC ---
> > I question whether that's possible/safe at the point where ctors are already
> > being called. If dlopen did not catch it but just let the caller catch it, what
> > would the caller be expected to do?
> 
> Whatever it would have done if dlopen() was a direct call to foo() instead.

This makes no sense. Unless dlopen is handling the exception, the internal
state of the dynamic linker is in an inconsistent state, possibly with locks
still held and some libraries loaded but without their constructors having been
called.

Note that the caller has no way to even get the library handle and pass it to
dlclose, because dlopen did not return.

> The bottom line is that if you are in a try/catch, and an exception is thrown,
> and that exception doesn't make it to your catch, then your language support is
> arguably busted/incomplete.

I disagree. Your catch is separated from the throw by multiple foreign function
calls. dlopen is not part of the C++ language; it's part of POSIX, which has no
relationship with C++, and is under no obligation to allow exceptions to
propagate across it. If I'm not mistaken, the C++ standard makes it explicit
that throwing an exception in C++ code that was reached as a callback from a C
function results in undefined behavior if the exception propagates out across
the C/C++ boundary.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.