This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]