2003-04-09 Andrew Cagney <cagney@redhat.com>

	* frame.h (struct frame_id): Replace "pc" and "base" with
	"stack_addr" and "code_addr".  Update comments.
	(frame_id_build): Update parameter names and comment.
	(struct frame_info): Replace "id_p" and "id" with "this_id".
	* dummy-frame.c (dummy_frame_this_id): Update.
	* breakpoint.c (print_one_breakpoint): Update.
	* frame.c (get_frame_id): Update.
	(get_frame_base, frame_id_build): Update.
	(create_sentinel_frame, legacy_get_prev_frame): Update.
	(deprecated_update_frame_base_hack): Update.
	(frame_id_p, frame_id_eq): Rework, return 0 when an invalid ID.
	(frame_id_inner): Ditto.

1 files changed, 28 insertions, 17 deletions

diff --git a/gdb/frame.h b/gdb/frame.h
index f3d2dea..2468fc9 100644
--- a/gdb/frame.h
+++ b/gdb/frame.h
@@ -44,15 +44,24 @@ struct frame_info;
 
 struct frame_id
 {
-  /* The frame's address.  This should be constant through out the
-     lifetime of a frame.  */
+  /* The frame's stack address.  This shall be constant through out
+     the lifetime of a frame.  Note that this requirement applies to
+     not just the function body, but also the prologue and (in theory
+     at least) the epilogue.  Since that value needs to fall either on
+     the boundary, or within the frame's address range, the frame's
+     outer-most address (the inner-most address of the previous frame)
+     is used.  Watch out for all the legacy targets that still use the
+     function pointer register or stack pointer register.  They are
+     wrong.  */
   /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two
      frame bases.  This will need to be expanded to accomodate that.  */
-  CORE_ADDR base;
-  /* The frame's current PC.  While the PC within the function may
-     change, the function that contains the PC does not.  Should this
-     instead be the frame's function?  */
-  CORE_ADDR pc;
+  CORE_ADDR stack_addr;
+  /* The frame's code address.  This shall be constant through out the
+     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().  */
+  CORE_ADDR code_addr;
 };
 
 /* Methods for constructing and comparing Frame IDs.
@@ -66,12 +75,12 @@ struct frame_id
 /* For convenience.  All fields are zero.  */
 extern const struct frame_id null_frame_id;
 
-/* Construct a frame ID.  The second parameter isn't yet well defined.
-   It might be the containing function, or the resume PC (see comment
-   above in `struct frame_id')?  A func/pc of zero indicates a
-   wildcard (i.e., do not use func in frame ID comparisons).  */
-extern struct frame_id frame_id_build (CORE_ADDR base,
-				       CORE_ADDR func_or_pc);
+/* Construct a frame ID.  The first parameter is the frame's constant
+   stack address (typically the outer-bound), and the second the
+   frame's constant code address (typically the entry point) (or zero,
+   to indicate a wild card).  */
+extern struct frame_id frame_id_build (CORE_ADDR stack_addr,
+				       CORE_ADDR code_addr);
 
 /* Returns non-zero when L is a valid frame (a valid frame has a
    non-zero .base).  */
@@ -397,10 +406,12 @@ struct frame_info
       int p;
     } prev_func;
 
-    /* This frame's ID.  Note that the frame's ID, base and PC contain
-       redundant information.  */
-    int id_p;
-    struct frame_id id;
+    /* This frame's ID.  */
+    struct
+    {
+      int p;
+      struct frame_id value;
+    } this_id;
 
     /* The frame's high-level base methods, and corresponding cache.
        The high level base methods are selected based on the frame's