Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()
Date: Mon, 05 Jan 2004 20:33:00 -0000	[thread overview]
Message-ID: <200401052033.i05KXcxx000617@elgar.kettenis.dyndns.org> (raw)

As suggested by Andrew, this removes the attempt to unwind the PC in
frame.c:get_prev_frame().  This bit of code shouldn't be necessary and
made it impossible to backtrace from a sentinel frame with PC == 0,
which would aroise from calling a null function pointer.

Andrew, I saw no use for retaining some of the commentd, so I delete
the thing completely.

Committed,

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* frame.c (get_prev_frame): Don't try to unwind the PC.  This
	fixes PR backtrace/1476.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.153
diff -u -p -r1.153 frame.c
--- frame.c 10 Dec 2003 17:40:42 -0000 1.153
+++ frame.c 5 Jan 2004 20:27:20 -0000
@@ -1943,37 +1943,6 @@ get_prev_frame (struct frame_info *this_
   prev_frame = FRAME_OBSTACK_ZALLOC (struct frame_info);
   prev_frame->level = this_frame->level + 1;
 
-  /* Try to unwind the PC.  If that doesn't work, assume we've reached
-     the oldest frame and simply return.  Is there a better sentinal
-     value?  The unwound PC value is then used to initialize the new
-     previous frame's type.
-
-     Note that the pc-unwind is intentionally performed before the
-     frame chain.  This is ok since, for old targets, both
-     frame_pc_unwind (nee, FRAME_SAVED_PC) and
-     DEPRECATED_FRAME_CHAIN()) assume THIS_FRAME's data structures
-     have already been initialized (using
-     DEPRECATED_INIT_EXTRA_FRAME_INFO) and hence the call order
-     doesn't matter.
-
-     By unwinding the PC first, it becomes possible to, in the case of
-     a dummy frame, avoid also unwinding the frame ID.  This is
-     because (well ignoring the PPC) a dummy frame can be located
-     using THIS_FRAME's frame ID.  */
-
-  if (frame_pc_unwind (this_frame) == 0)
-    {
-      /* The allocated PREV_FRAME will be reclaimed when the frame
-	 obstack is next purged.  */
-      if (frame_debug)
-	{
-	  fprintf_unfiltered (gdb_stdlog, "-> ");
-	  fprint_frame (gdb_stdlog, NULL);
-	  fprintf_unfiltered (gdb_stdlog, " // unwound PC zero }\n");
-	}
-      return NULL;
-    }
-
   /* Don't yet compute ->unwind (and hence ->type).  It is computed
      on-demand in get_frame_type, frame_register_unwind, and
      get_frame_id.  */


             reply	other threads:[~2004-01-05 20:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-05 20:33 Mark Kettenis [this message]
2004-01-05 21:57 ` Andrew Cagney
2004-01-05 23:01   ` Mark Kettenis
2004-01-05 23:46     ` Andrew Cagney

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=200401052033.i05KXcxx000617@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --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