This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11610] _init/_fini do not have proper unwinding information
- From: "ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sun, 28 Oct 2012 00:16:36 +0000
- Subject: [Bug libc/11610] _init/_fini do not have proper unwinding information
- Auto-submitted: auto-generated
- References: <bug-11610-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11610
--- Comment #5 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-10-28 00:16:36 UTC ---
(In reply to comment #4)
> I'm curious what the "right" behavior in this circumstance would be. Are you
> suggesting dlopen should catch the exception and back out the whole operation?
No, I am not suggesting that.
> 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.
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.
> Throwing exceptions from global ctors
> (well, even having global ctors to begin with, but that's another topic
> entirely) just strikes me as a flawed library design.
No argument there. Please note that the entire dlopen/throw example was
constructed to demonstrate that the lack of unwind info in _init is not just a
GDB problem, but a potential problem in other contexts as well.
--
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.