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

[David Mosberger]

>>>>> On Fri, 26 Mar 2004 13:26:14 +0100, Johan Walles <address@hidden> said:

  Johan> 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.

  Johan> That would be just *super*!

No, it would be a nightmare.

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

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

Nice try.  Backwards compatibility becomes an issue as soon as there
is shipping code.  libunwind is already being adopted by various
distributors.  It doesn't matter what the version number is.

  >>  Can you tell me what the performance issue is?

  Johan> What we use libunwind for in our shipment builds are:

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

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

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

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

I'm sorry, but your argument makes no sense at all.  You're now saying
again that unwinding is rare.  If so, the best solution is to do the
unw_getcontext() at the time the unwind is needed and then skip the
intervening frames until you hit the signal frame.  This will have
ZERO impact on the normal case and thanks to the caching in libunwind,
will work with good performance even when you do need to unwind.

Please, if you really care about performance, present real numbers
(and a test-case).  I'm not going to screw up a carefully balanced and
performant API just because of some hypothetical performance issues.
If there _is_ a real performance issue, I'll do anything I can to
address that.

        --david