Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung <randolph at tausq dot org>]

> Let me see if i can rework this a bit. The problem is that when you
> have:
> 
> signal frame
> <signal trampoline>
> normal frame
> <dummy frame, code called from gdb>
> 
> 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  <signal handler called>
#2  func1 () at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:28
#3  <function called from gdb>
../../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 <func1+0>:   copy r3,r1
0x000105f4 <func1+4>:   copy sp,r3
0x000105f8 <func1+8>:   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/