From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfa/hppa] Use frame pointer for unwinding Date: Mon, 17 May 2004 00:13:00 -0000 Message-id: <20040517001310.GO566@tausq.org> References: <20040516020703.GZ566@tausq.org> <40A78B63.9020102@gnu.org> <20040516170257.GM566@tausq.org> X-SW-Source: 2004-05/msg00477.html > Let me see if i can rework this a bit. The problem is that when you > have: > > signal frame > > normal frame > > > the stack pointer in the dummy frame is wrong. the dummy frame uses the > sp returned by push_dummy_call () as the sp, but the unwinder follows > the frame pointer saved by the signal trampoline, and they don't match. i think the problem is this -- i am looking at a failure in signals.exp. there is a signal handler setup for SIGALARM. We "schedule" a signal to be delivered via alarm(1), then do a "p func1()", and then a backtrace from the signal handler: Breakpoint 2, handler (sig=14) at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:22 22 signal (sig, handler); The program being debugged stopped while in a function called from GDB. When the function (func1) is done executing, GDB will silently stop (instead of continuing to evaluate the expression containing the function call). (gdb) bt #0 handler (sig=14) at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:22 #1 #2 func1 () at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:28 #3 ../../gdb-work/gdb/dummy-frame.c:300: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n What seems to be happening is that the signal handler is triggered before the frame pointer is stored in func1: (gdb) disassemble func1 Dump of assembler code for function func1: 0x000105f0 : copy r3,r1 0x000105f4 : copy sp,r3 0x000105f8 : stw,ma r1,40(sr0,sp) [...] the signal is triggered at 0x105f0, but the frame pointer is not saved till 0x105f8. So, during unwinding, we notice that the signal frame has the frame pointer stored, and use that to unwind the stack. Oops. So, either: - we don't allow the frame pointer to be used if the next frame is a SIGTRAMP_FRAME (similar to what i had before) or: - in the sigtramp unwinder, we don't restore the frame pointer what is a better solution? or can anyone suggest a better alternative? thanks randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/