Paul, Arun -- thank you both for the clarifications, they were very helpful.
On 9/25/09 1:11 PM, "Paul Pluzhnikov" <[email protected]> wrote: > On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <[email protected]> wrote: > >> I read this: >> http://lists.nongnu.org/archive/html/libunwind-devel/2009-09/msg00000.html >> >> But I was a little unclear on the main motivation. >> >> Was the motivation that the existing signal blocking mechanism didn't >> prevent re-entry? If it didn't prevent it, did it cause crashes or aborted >> stack traces or what was the symptom? > > Existing mechanism did prevent re-entry, but at a cost of lots of > sigprocmask()s. We have one particular (emulated) environment, where these > are quite costly. > >> If you're now planning to block additional signals in your own client code >> ("at the top level"), > > We don't actually need to block them, we just need to make sure that the > same thread doesn't reenter libunwind from a signal handler.... > >> are you removing the calls inside libunwind to ensure >> it doesn't unblock them (as it does SETMASK), > > The remaining sigprocmask calls are following this pattern: > > sigprocmask (SIG_SETMASK, &unwi_full_mask, &saved_mask); > ret = dl_iterate_phdr (check_callback, as); > sigprocmask (SIG_SETMASK, &saved_mask, NULL); > > so (AFAICT) they wouldn't unblock anything that was blocked before. > > But I see now that I should have eliminated these remaining sigprocmasks > as well. Patch attached. > >> or are you just removing them >> for performance since they're unnecessary as your initial message implies? > > Yes. > >> Finally, I just wanted to get a clarification on the effects of linking >> libunwind -- it was my impression that linking it may also affect the stack >> unwinding done when, for instance, a C++ exception is thrown. > > Not by default. In default configuration on x86_64, I get: > > nm -D src/.libs/libunwind.so | grep ' T ' | grep -v ' _U' > 0000000000001380 T backtrace > > So only calls to (glibc) backtrace would be affected. > > Cheers, _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
