From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
Description of problem:
When debugging a program that uses an alternative stack (do man sigaltstack),
doing "bt" inside a signal handler should show me the stack frames before the
handler was called.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Debug a program that uses an alternative stack for signal handling. Put a
breakpoint inside a signal handler and pass the appropriate signal to the
program. When you've stopped at the breakpoint, do "bt".
Actual Results: Stack frames are shown, but only on this side of the call to
the signal handler. What the program was doing when the signal was received is
impossible to tell from the backtrace.
Expected Results: All stack frames, even the ones on the ordinary stack, should
have been shown. Then I could tell just from doing "bt" what the program was
doing when the signal arrived.
Will upload a test program demonstrating the problem. Note that this works fine
Created attachment 86724 [details]
Demo program. Break in "handler" and do "bt" there. The main() function doesn't appear in the backtrace.
Apparently Mosberger has already solved this problem using his libunwind. Both
libunwind and a patch to gdb to make it use libunwind are available at
"ftp://ftp.hpl.hp.com/pub/linux-ia64/". Haven't tried them yet, but they are
rumored to resolve this problem.
They do resolve the problem in the general case. However, in its current
incarnation this behaves even worse than gdb proper when dealing with our
dynamically generated code (I'm not blaming them...), and thus this doesn't
resolve our original problem. So while this patched version of gdb is probably
the way to go, from our point of view it is not there yet.
Unforturnately I don't think this is anything you guys can do anything about, so
I'm closing this. If you want to fix this for any of your other customers, feel
free to re-open.