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

["John David Anglin" <dave@hiauly1.hia.nrc.ca>]

> ok. there is no gcc bug yet, but i will file one.

Bug?

> the fp != 0 is there probably because i don't understand correctly how
> the unwinder is working. if you have three frames:

> frame 3 - unwind from here
> frame 2 - doesn't save fp; fp should be constant in this function
> frame 1 - saves fp

Note that the the previous SP (frame pointer) is saved in the frame
marker of frame 1.  This value is accessible from frame 2 (i.e.,
effectively the frame pointer is always saved under hpux when Save_SP
is true -- it's just done by the caller).  However, I think gdb
should avoid using the saved SP value in the frame marker as not
all versions of GCC support this.  It's also not supported under
linux.

There are basically three situations generated by GCC:

1) The previous SP is saved at the start of the frame, the frame has
   a frame pointer (all alloca frames have a frame pointer) and Save_SP
   is set in the callinfo data.  Under hpux, the previous SP value
   is also saved at SP - 4 (8 on hppa64) in the frame marker.  This
   value is copied when a stack adjustment is done (i.e., the frame
   marker moves).

2) The frame uses register %r3 but doesn't have a frame pointer.  In
   this case, %r3 is saved along with the other general registers.

3) The frame does have a frame pointer or use %r3.  %r3 is not saved
   in the frame.

> frame 3 gets frame 2 as next_frame, will it be able to get the value of
> fp (from what is saved in frame 1)? it seems to work in my tests, but 
> i haven't yet figured out how it works in the code. if frame 2 doesn't
> save a register in its cache, is there some code that by default 
> propagates the values from the next frame?

If frame doesn't save %r3 either using method 1 or 2, then frame 2
leaves %r3 unchanged.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)