This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Make PowerPC backtraces more robust
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Wed, 28 Sep 2005 10:10:00 -0700
- Subject: Re: RFC: Make PowerPC backtraces more robust
- References: <20050923193403.GA7146@nevyn.them.org>
On Fri, 23 Sep 2005 15:34:03 -0400
Daniel Jacobowitz <drow@false.org> wrote:
> Index: rs6000-tdep.c
> ===================================================================
> RCS file: /big/fsf/rsync/src/src/gdb/rs6000-tdep.c,v
> retrieving revision 1.243
> diff -u -p -r1.243 rs6000-tdep.c
> --- rs6000-tdep.c 19 Sep 2005 17:38:03 -0000 1.243
> +++ rs6000-tdep.c 23 Sep 2005 18:26:39 -0000
> @@ -2852,6 +2852,7 @@ rs6000_frame_cache (struct frame_info *n
> struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> struct rs6000_framedata fdata;
> int wordsize = tdep->wordsize;
> + CORE_ADDR func, pc;
>
> if ((*this_cache) != NULL)
> return (*this_cache);
> @@ -2859,35 +2860,56 @@ rs6000_frame_cache (struct frame_info *n
> (*this_cache) = cache;
> cache->saved_regs = trad_frame_alloc_saved_regs (next_frame);
>
> - skip_prologue (frame_func_unwind (next_frame), frame_pc_unwind (next_frame),
> - &fdata);
> + func = frame_func_unwind (next_frame);
> + pc = frame_pc_unwind (next_frame);
> + skip_prologue (func, pc, &fdata);
> +
> + /* Figure out the parent's stack pointer. */
> +
> + /* NOTE: cagney/2002-04-14: The ->frame points to the inner-most
> + address of the current frame. Things might be easier if the
> + ->frame pointed to the outer-most address of the frame. In
> + the mean time, the address of the prev frame is used as the
> + base address of this frame. */
> + cache->base = frame_unwind_register_unsigned (next_frame, SP_REGNUM);
> +
> + /* If the function appears to be frameless, check a couple of likely
> + indicators that we have simply failed to find the frame setup.
> + Two common cases of this are missing symbols (i.e.
> + frame_func_unwind returns the wrong address or 0), and assembly
> + stubs which have a fast exit path but set up a frame on the slow
> + path.
> +
> + If the LR appears to return to this function, then presume that
> + we have an ABI compliant frame that we failed to find. */
> + if (fdata.frameless && fdata.lr_offset == 0)
> + {
> + CORE_ADDR saved_lr;
> + int make_frame = 0;
> +
> + func = frame_func_unwind (next_frame);
It appears to me that func has already been computed earlier in this
function and that the value should be the same.
The rest looks okay to me.
Kevin