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

[David Mosberger]

Hi Max,

>>>>> On Fri, 26 Mar 2004 11:58:26 -0800, Max Asbock <address@hidden> said:

  Max> On x86_64 we can't currently unwind across signal frames using
  Max> dwarf2 info. The kernel doesn't export that information yet.
  Max> See http://www.x86-64.org/lists/discuss/msg04811.html Therefore
  Max> even if we call unw_getcontext() from the signal handler and
  Max> unwind back till we hit the signal frame, we still have to pick
  Max> out the values for the next SP and IP from the ucontext on the
  Max> signal frame. I am not sure if this is different from using the
  Max> same ucontext passed in by the signal handler directly.

This is really a different problem, though.  Unwinding across signal
handlers always _should_ work.  In the case of x86-64, I'm not sure
whether the right answer is (a) just wait until fixed kernels are
wide-spread enough or (b) put in a work-around which patches the
unwind state appropriately for the old/broken kernels.  For (b), you
could look at what GCC does in the MD_FALLBACK_STATE() macro for
x86-64.  If you do the equivalent thing in libunwind, you should be
able to unwind across signal-handlers.

BTW: This reminds me: it would really be useful to have signal frames
marked in a way that makes them easy to detect.  At the moment, the
x86-implementation of unw_is_signal_frame() has to read the code to
detect signal-frames, which is inefficient and not necessarily 100%
reliable.  I suggested that to Rich Henderson at one point, but he
pushed back on it because he thought that "all stack frames should be
equal".  Well, signal frames _are_ special and applications do care
about detecting them and if you agree, you may want to bring up the
issue again with the x86-64 kernel folks.  It should be very easy to
put a suitable marker in the DWARF unwind info.

        --david