From d0a557723ac537e04c5be236aada4b6db0bf6ab5 Mon Sep 17 00:00:00 2001 From: Andrew Cagney Date: Thu, 10 Apr 2003 03:30:36 +0000 Subject: 2003-04-09 Andrew Cagney * 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. --- gdb/frame.h | 45 ++++++++++++++++++++++++++++----------------- 1 file changed, 28 insertions(+), 17 deletions(-) (limited to 'gdb/frame.h') 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 -- cgit v1.1