Hide Forgot
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): How reproducible: Always 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. Additional info: Will upload a test program demonstrating the problem. Note that this works fine on IA32.
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.