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

[Randolph Chung <randolph@tausq.org>]

In reference to a message from John David Anglin, dated May 17:
> > ok. there is no gcc bug yet, but i will file one.
> 
> Bug?

ok, feature request? ;-) as noted below this is not really required for
gdb to work correctly; i'm just wondering if the same Save_SP scheme
works for both hp compiler and gcc. In some other email you had
indicated that the hp compiler doesn't set the Save_SP flag (or did 
i misunderstand you?)....

> 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.

right now gdb uses the value of the frame pointer that is stored at the
start of the frame; that is, for "normal frames", it looks for a
specific code sequence:

stw,ma rN, xxx(sp)

in the code, and if it sees this, it notes that a frame pointer has 
been stored at offset 0 of the stack. During unwinding, it finds out 
if the current frame should have saved the fp (by looking at the Save_SP
flag) and if so it retrieves it from the stack.

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

right; my question was more about how the value of the register gets
propagated in the gdb data structures. will look at the code some more.

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