Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFC: Make PowerPC backtraces more robust
Date: Wed, 28 Sep 2005 17:10:00 -0000	[thread overview]
Message-ID: <20050928101000.0038099a@ironwood.lan> (raw)
In-Reply-To: <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


  reply	other threads:[~2005-09-28 17:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-23 19:34 Daniel Jacobowitz
2005-09-28 17:10 ` Kevin Buettner [this message]
2005-09-29 15:38   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050928101000.0038099a@ironwood.lan \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox