From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10525 invoked by alias); 19 Nov 2002 20:04:21 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 10518 invoked from network); 19 Nov 2002 20:04:19 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 19 Nov 2002 20:04:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 91F553E39 for ; Tue, 19 Nov 2002 15:04:15 -0500 (EST) Message-ID: <3DDA993F.8050601@redhat.com> Date: Tue, 19 Nov 2002 12:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: insight@sources.redhat.com Subject: [patch/hold] FRAME_FP() -> get_frame_base() Content-Type: multipart/mixed; boundary="------------040308090003000502050603" X-SW-Source: 2002-q4/txt/msg00120.txt.bz2 This is a multi-part message in MIME format. --------------040308090003000502050603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2698 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. */ + --------------040308090003000502050603 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 935 2002-11-19 Andrew Cagney * 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); --------------040308090003000502050603--