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

[Randolph Chung <randolph at tausq dot org>]

> The unwinder shouldn't need to doing things conditional on the type of 
> the next frame.  

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.

> What does ``Variable_Frame'' mean?

9. Variable_Frame (bit 17): Indicates that this region.s frame may be 
expanded during the region.s execution (using the Ada dynamic frame 
facility). Such frames require different unwinding techniques.

actually what you are probably interested in is this:

26. alloca_frame (bit 35): This bit is set if alloca() is used and has 
been inlined. This indicates gr3 or gr4 may contain the previous sp 
value.

For some reason this latter flag is named differently in the gdb sources
compared to what's in the documentation.

Anyway, I spoke with Dave Anglin (hppa gcc maintainer) about this. The
problem is that currently gcc/binutils does not correctly implement the
alloca_frame bit. The frame pointer is maintained in the case of a
variable-sized frame, but there is no flag set in the unwind record, and
the frame layout is slightly different compared to the HP compiler. It's
one of the things that should be fixed in gcc eventually. Also Dave has
observed that the Save_SP bit is set only for gcc; with the HP compiler
this is not set.  Finally, with the HP compiler the frame pointer can 
be maintained either in r3 or r4. It's not clear yet how this works. 
Some more experimentation/disassembling HP code is required :-( 
I will add some comments to the code about this situation.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/