[PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()

[PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()

[Mark Kettenis]

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.  */

Re: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()

[Andrew Cagney]

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

Can just you add a -ve comment stating why a test for PC==0 does not 
belong in that function?  I'm pretty much certain that someone will 
eventually try to re-add a very similar test (via inside_entry_func for 
instance).

Andrew

Re: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()

[Mark Kettenis]

   Date: Mon, 05 Jan 2004 16:57:15 -0500
   From: Andrew Cagney <cagney@gnu.org>

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

   Can just you add a -ve comment stating why a test for PC==0 does not 
   belong in that function?  I'm pretty much certain that someone will 
   eventually try to re-add a very similar test (via inside_entry_func for 
   instance).

Well, I just added a regression test, shouldn't that be enough?

(You just reminded me that I should remove the PC == 0 check from
inside_entry_func too).

Mark

Re: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()

[Andrew Cagney]

>    Date: Mon, 05 Jan 2004 16:57:15 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    > Andrew, I saw no use for retaining some of the commentd, so I delete
>    > the thing completely.
> 
>    Can just you add a -ve comment stating why a test for PC==0 does not 
>    belong in that function?  I'm pretty much certain that someone will 
>    eventually try to re-add a very similar test (via inside_entry_func for 
>    instance).
> 
> Well, I just added a regression test, shouldn't that be enough?

Not round here :-(  Better to retain the relevant information so that 
the rationale is written down and available at our finger tips.   If you 
don't want to do it, I will.

Andrew

> (You just reminded me that I should remove the PC == 0 check from
> inside_entry_func too).