[libunwind] Re: Is this possible with libunwind?

[David Mosberger]

Hi Chris,

>>>>> On Tue, 15 Apr 2003 12:47:19 -0700, Chris Markle <address@hidden> said:

  Chris> David, Could one use libunwind to accomplish the following,
  Chris> and if so, can you offer a hint or two as to which calls
  Chris> would be involved?

  Chris> The idea here is to:

  Chris> 1) catch SIGSEGV in a signal handler (that part is easy).

  Chris> 2) print or emit in some way a stack trace. Best if it could
  Chris> be a stack trace as if the signal handler wasn't in the
  Chris> picture - the same kind of trace you'd get from gdb of an
  Chris> application that hadn't caught SIGSEGV.

  Chris> 3) somehow "unwind" (or whatever) so that the application
  Chris> runs as if the signal had not been caught. That is, return to
  Chris> the application at point of the SIGSEGV and let it core as if
  Chris> the signal had not been caught.

  Chris> The intent here is to generate as close as possible of a
  Chris> core, including a "clean" backtrace, even while catching the
  Chris> SIGSEGV so as to be able to emit some backtrace info.

Yes, that's should be possible:

 (1) In the signal handler, do an unw_getcontext() & unw_init_local(),
     then call unw_step() until unw_is_signal_frame() returns TRUE.
     Doing one more unw_step() will get you to the frame in which the
     signal occurred.

 (2) For the current frame, print the info you want (instruction-pointer,
     procedure name, etc.), then call unw_step().  Repeat step (2) until
     unw_step() returns a value <= 0.

 (3) Reset the SIGSEGV signal handler to SIG_DFL and then return from
     the signal handler.

After returning from the signal handler, the faulting instruction will
be re-executed.  It will fault again and now the default signal
handling will apply, i.e., a core-dump will be created (I suppose an
alternative would be to call abort() directly from the signal
handler; IIRC, abort() is signal-safe).

Of course, in theory you could get the backtrace from the core dump,
but gdb isn't quite up to speed yet for that (it's being fixed,
though).

If you want to see some sample code, do_backtrace() in tests/bt.c
should be a good starting point.

        --david