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

[Mark Rabkin]

Thanks for the speedy response ;)


On 9/25/09 11:41 AM, "Paul Pluzhnikov" <address@hidden> wrote:

> On Fri, Sep 25, 2009 at 11:29 AM, Mark Rabkin <address@hidden> wrote:
> 
>> Sorry to jump in late here but could you give a couple more sentences of
>> clarification of what this patch intends to accomplish?
> 
> Which "this" patch? (There are several in this thread.)
> 

I meant the signal blocking one (since this was the one under discussion).
I see the patch code, I was just wondering what the motivation was.

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?

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?

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.

- Mark