[commit] Remove frame_func_unwind

[Daniel Jacobowitz <drow@false.org>]

A number of frame unwind functions are no longer necessary now that
unwinders get the current frame.  This patch removes
frame_func_unwind; tested on x86_64-linux and committed.

-- 
Daniel Jacobowitz
CodeSourcery

2008-07-15  Daniel Jacobowitz  <dan@codesourcery.com>

	* frame.c (frame_func_unwind): Delete.
	(get_frame_func): Do not use it.
	* frame.h (frame_func_unwind): Delete prototype.
	* hppa-tdep.c (hppa_frame_cache): Update comment.
	* rs6000-tdep.c (rs6000_frame_cache): Update comment.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.244
diff -u -p -r1.244 frame.c
--- frame.c	9 Jul 2008 22:16:14 -0000	1.244
+++ frame.c	15 Jul 2008 18:10:36 -0000
@@ -461,27 +461,24 @@ frame_pc_unwind (struct frame_info *this
 }
 
 CORE_ADDR
-frame_func_unwind (struct frame_info *fi, enum frame_type this_type)
+get_frame_func (struct frame_info *this_frame)
 {
-  if (!fi->prev_func.p)
+  struct frame_info *next_frame = this_frame->next;
+
+  if (!next_frame->prev_func.p)
     {
       /* Make certain that this, and not the adjacent, function is
          found.  */
-      CORE_ADDR addr_in_block = frame_unwind_address_in_block (fi, this_type);
-      fi->prev_func.p = 1;
-      fi->prev_func.addr = get_pc_function_start (addr_in_block);
+      CORE_ADDR addr_in_block = get_frame_address_in_block (this_frame);
+      next_frame->prev_func.p = 1;
+      next_frame->prev_func.addr = get_pc_function_start (addr_in_block);
       if (frame_debug)
 	fprintf_unfiltered (gdb_stdlog,
-			    "{ frame_func_unwind (fi=%d) -> 0x%s }\n",
-			    fi->level, paddr_nz (fi->prev_func.addr));
+			    "{ get_frame_func (this_frame=%d) -> 0x%s }\n",
+			    this_frame->level,
+			    paddr_nz (next_frame->prev_func.addr));
     }
-  return fi->prev_func.addr;
-}
-
-CORE_ADDR
-get_frame_func (struct frame_info *fi)
-{
-  return frame_func_unwind (fi->next, get_frame_type (fi));
+  return next_frame->prev_func.addr;
 }
 
 static int
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.164
diff -u -p -r1.164 frame.h
--- frame.h	21 May 2008 15:08:39 -0000	1.164
+++ frame.h	15 Jul 2008 18:10:36 -0000
@@ -99,7 +99,7 @@ struct frame_id
      lifetime of the frame.  While the PC (a.k.a. resume address)
      changes as the function is executed, this code address cannot.
      Typically, it is set to the address of the entry point of the
-     frame's function (as returned by frame_func_unwind().  
+     frame's function (as returned by get_frame_func).
 
      This field is valid only if code_addr_p is true.  Otherwise, this
      frame is considered to have a wildcard code address, i.e. one that
@@ -300,11 +300,6 @@ extern CORE_ADDR frame_sp_unwind (struct
    that function isn't known.  */
 extern CORE_ADDR get_frame_func (struct frame_info *fi);
 
-/* Similar to get_frame_func, find the start of the function which
-   logically called NEXT_FRAME, assuming it is a THIS_TYPE frame.  */
-extern CORE_ADDR frame_func_unwind (struct frame_info *next_frame,
-				    enum frame_type this_type);
-
 /* Closely related to the resume address, various symbol table
    attributes that are determined by the PC.  Note that for a normal
    frame, the PC refers to the resume address after the return, and
Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.252
diff -u -p -r1.252 hppa-tdep.c
--- hppa-tdep.c	26 Jun 2008 15:51:28 -0000	1.252
+++ hppa-tdep.c	15 Jul 2008 18:10:37 -0000
@@ -1894,9 +1894,9 @@ hppa_frame_cache (struct frame_info *thi
        in hppa_skip_prologue will return a prologue end that is too early
        for us to notice any potential frame adjustments.  */
 
-    /* We used to use frame_func_unwind () to locate the beginning of the
-       function to pass to skip_prologue ().  However, when objects are 
-       compiled without debug symbols, frame_func_unwind can return the wrong 
+    /* We used to use get_frame_func to locate the beginning of the
+       function to pass to skip_prologue.  However, when objects are
+       compiled without debug symbols, get_frame_func can return the wrong
        function (or 0).  We can do better than that by using unwind records.  
        This only works if the Region_description of the unwind record
        indicates that it includes the entry point of the function.  
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.317
diff -u -p -r1.317 rs6000-tdep.c
--- rs6000-tdep.c	10 Jul 2008 19:40:43 -0000	1.317
+++ rs6000-tdep.c	15 Jul 2008 18:10:37 -0000
@@ -2509,7 +2509,7 @@ rs6000_frame_cache (struct frame_info *t
   /* 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
+     get_frame_func returns the wrong address or 0), and assembly
      stubs which have a fast exit path but set up a frame on the slow
      path.