|
From: | Young, Mark |
Subject: | Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work) |
Date: | Fri, 26 Mar 2004 08:41:09 -0800 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
Johan Walles wrote:
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*!
I second the motion. Using a signal context to start unwinding would be useful in our application.
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.
In addition to the above sorts of uses, we use libunwind to implement a time-sampled call-stack profiler. On each interval timer signal, we unwind and capture the call stack. The interrupts are frequent and anything done to improve performance would be helpful.
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 _______________________________________________ libunwind mailing list address@hidden http://www.hpl.hp.com/hosted/linux/mail-archives/libunwind/
--Mark Young
[Prev in Thread] | Current Thread | [Next in Thread] |