[patch/hold] FRAME_FP() -> get_frame_base()

[Andrew Cagney <ac131313 at redhat dot com>]

Just FYI,

This patch updates insight to match a proposed "frame.h" interface 
change.  Once that interface change is in, this, or an equivalent will 
(hopefully) be committed.

The patch adds a FIXME which the Insight people may want to note.  The 
appended text (part of the GDB patch) hopefully provides additional 
information on the problem.

Andrew

+/* Return the frame address from FI.  Except in the machine-dependent
+   *FRAME* macros, a frame address has no defined meaning other than
+   as a magic cookie which identifies a frame over calls to the
+   inferior (um, SEE NOTE BELOW).  The only known exception is
+   inferior.h (PC_IN_CALL_DUMMY) [ON_STACK]; see comments there.  You
+   cannot assume that a frame address contains enough information to
+   reconstruct the frame; if you want more than just to identify the
+   frame (e.g. be able to fetch variables relative to that frame),
+   then save the whole struct frame_info (and the next struct
+   frame_info, since the latter is used for fetching variables on some
+   machines) (um, again SEE NOTE BELOW).
+
+   NOTE: cagney/2002-11-18: Actually, the frame address isn't
+   sufficient for identifying a frame, and the counter examples are
+   wrong!
+
+   Code that needs to (re)identify a frame must use get_frame_id() and
+   frame_find_by_id() (and in the future, a frame_compare() function
+   instead of INNER_THAN()).  Two reasons: an architecture (e.g.,
+   ia64) can have more than one frame address (due to multiple stack
+   pointers) (frame ID is going to be expanded to accomodate this);
+   successive frameless function calls can only be differientated by
+   comparing both the frame's base and the frame's enclosing function
+   (frame_find_by_id() is going to be modified to perform this test).
+
+   The generic dummy frame version of PC_IN_CALL_DUMMY() is able to
+   identify a dummy frame using only the PC value.  So the frame
+   address is not needed.  In fact, most PC_IN_CALL_DUMMY() calls now
+   pass zero as the frame/sp values as the caller knows that those
+   values won't be used.  Once all architectures are using generic
+   dummy frames, PC_IN_CALL_DUMMY() can drop the sp/frame parameters.
+   When it comes to finding a dummy frame, the next frame's frame ID
+   (with out duing an unwind) can be used (ok, could if it wasn't for
+   the need to change the way the PPC defined frame base in a strange
+   way).
+
+   Modern architectures should be using something like dwarf2's
+   location expression to describe where a variable lives.  Such
+   expressions specify their own debug info centric frame address.
+   Consequently, a generic frame address is pretty meaningless.  */
+
2002-11-19  Andrew Cagney  <ac131313@redhat.com>

	* generic/gdbtk-stack.c (gdb_selected_frame): Use get_frame_base
	instead of FRAME_FP.  Mention that get_frame_id() should be used.
	
Index: generic/gdbtk-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-stack.c,v
retrieving revision 1.11
diff -u -r1.11 gdbtk-stack.c
--- generic/gdbtk-stack.c	19 Nov 2002 19:33:46 -0000	1.11
+++ generic/gdbtk-stack.c	19 Nov 2002 20:00:51 -0000
@@ -420,7 +420,9 @@
   if (selected_frame == NULL)
     xasprintf (&frame, "%s","");
   else
-    xasprintf (&frame, "0x%s", paddr_nz (FRAME_FP (selected_frame)));
+    /* FIXME: cagney/2002-11-19: This should be using get_frame_id()
+       to identify the frame and *NOT* get_frame_base().  */
+    xasprintf (&frame, "0x%s", paddr_nz (get_frame_base (selected_frame)));
 
   Tcl_SetStringObj (result_ptr->obj_ptr, frame, -1);