Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work)

[Johan Walles]

David Mosberger wrote:
> > > > > > On Thu, 25 Mar 2004 11:04:34 +0100, Johan Walles <address@hidden> said:
>
>   Johan> Could you post an example of how my unwind.c could be
>   Johan> modified to do that very conversion correctly?
>
> It would require a non-trivial extension of libunwind.  What we
> _could_ do is to extend the meaning of the sc_flags member so it
> indicates whether it is a synchronous (think getcontext()) or
> asynchronous (think signal) context.  In the latter case, there would
> also have to be an implicit or explicit way of telling that the
> preserved registers are also in the context.
>
> With this in place, it would then be possible to extend
> unw_init_local() so it works for both synchronous and asynchronous
> contexts.

That would be just *super*!

> maintaining backwards compatibility
> would be challenging.  For example, the libc's getcontext() doesn't
> touch sc_flags at all.

Regarding libunwind itself, it's still at 0.96 so even though backwards 
compatibility would be nice to have, I can't see how backwards compatibility is 
a must-have until 1.0 has been released.

As for libc's getcontext(), I can see how changing that would break things. 
However, changing unw_getcontext() should still be possible.

Or why not add an unw_init_from_sigcontext_local()?  At least for us, keeping 
track of where we got the context from isn't a problem.  But if libunwind could 
take care of that itself, that would of course be cleaner the from the user's 
point of view.

> > > > > > On Thu, 25 Mar 2004 17:00:52 +0100, Johan Walles <address@hidden> said:
>
>   Johan> and to use getcontext() and step using libunwind every time a
>   Johan> signal is received (which I don't want to for performance
>   Johan> reasons).
>
> Can you tell me what the performance issue is?

What we use libunwind for in our shipment builds are:

1. When we've crashed, we dump a symbolic stacktrace to stderr.

2. When people ask what the Java threads are doing, we can optionally dump the C 
stack traces in addition to the Java stack traces.

Since both of these are quite rare, we'd like for them to incur as little 
overhead as possible in the common case.

So yes, it is that we get lots of signals but need to use libunwind only 
occasionally.

> If so,
> unw_getcontext() would be the performance-critical operation (not
> unw_init_local()).  I already sped up unw_getcontext() in the latest
> source code by removing the unnecessary sigprocmask() system call.
> Another thing that I'm likely to do is to add some prefetch
> instructions to improve the performance when the memory for
> unw_context_t is not in cache.  Another tweak that might be possible
> is to move the "flushrs" instruction out of unw_getcontext() and into
> unw_init_local().

As we already have a very nice context that we've just received from the kernel, 
and that we use for all our internal unwinding, it's a real pity that you say 
libunwind can't handle it.  If it could, that would be awesome!

  Cheers //Johan