From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfa/hppa] Use frame pointer for unwinding Date: Mon, 17 May 2004 17:27:00 -0000 Message-id: <40A8F5F6.9000704@gnu.org> References: <20040516020703.GZ566@tausq.org> <40A78B63.9020102@gnu.org> <20040516170257.GM566@tausq.org> <20040517001310.GO566@tausq.org> <20040517023428.GP566@tausq.org> <40A8D8E5.9000506@gnu.org> <20040517160124.GV566@tausq.org> X-SW-Source: 2004-05/msg00497.html >+ if (frame_pc_unwind (next_frame) >= prologue_end >+ && u->Save_SP && fp != 0) fp will effectively always be non-zero here, so the ``fp != 0'' is a just-in-case? Suggest adding that, and the GCC bug-number, as additions to the comments. ok. there is no gcc bug yet, but i will file one. 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 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 (I'm assuming that the above stack backtrace is in reverse order to what GDB would display) save a register in its cache, is there some code that by default propagates the values from the next frame? yes, if frame-2 didn't save fp, then the trad-frame code will assume that frame-3's fp value is frame-2's fp value, and there for ask frame-1 to unwind it (a recursive call). Andrew