From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung To: John David Anglin Cc: gdb-patches@sources.redhat.com, cagney@gnu.org Subject: Re: [patch/rfa/hppa] Use frame pointer for unwinding Date: Mon, 17 May 2004 17:28:00 -0000 Message-id: <20040517172821.GX566@tausq.org> References: <200405171713.i4HHDxc1006156@hiauly1.hia.nrc.ca> X-SW-Source: 2004-05/msg00498.html 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/