[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] Unwinding using the context passed to a signal handler (

From: Johan Walles
Subject: Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work)
Date: Fri, 26 Mar 2004 13:26:14 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]