Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.

[Arun Sharma]

On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <address@hidden> wrote:
>
> If you're now planning to block additional signals in your own client code
> ("at the top level"), are you removing the calls inside libunwind to ensure
> it doesn't unblock them (as it does SETMASK), or are you just removing them
> for performance since they're unnecessary as your initial message implies?
>

There were some users of libunwind who didn't like the sigprocmask()
system calls generated by libunwind (there were both performance and
usability reasons). Paul's patch to test-async-sig.c shows how reentry
into libunwind in the same thread can be prevented via a thread local
variable without doing a sigprocmask at the top level.

> 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.  Is that not
> the case by default?  You had mentioned that you use libunwind only for
> manually generated stack traces (as is my intention as well), so I wanted to
> make sure there's nothing special to be done to prevent libunwind from
> taking over some standard symbols that may affect other program behavior.

In 0.99, the default is to disable C++ exception handling, so there
are no side effects.

./configure --enable-cxx-exceptions

gives the old behavior.

 -Arun