From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20686 invoked by alias); 5 Apr 2003 15:56:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20666 invoked from network); 5 Apr 2003 15:56:50 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 5 Apr 2003 15:56:50 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9478C2B29 for ; Sat, 5 Apr 2003 10:56:45 -0500 (EST) Message-ID: <3E8EFCBD.6090401@redhat.com> Date: Sat, 05 Apr 2003 15:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [commit] Move legacy prev->next = ... earlier Content-Type: multipart/mixed; boundary="------------000106050009060506070807" X-SW-Source: 2003-04/txt/msg00082.txt.bz2 This is a multi-part message in MIME format. --------------000106050009060506070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 444 Hello, The function: get_frame_pc(fi) === fi->pc is about to be changed to: get_frame_pc(fi) === fi->next->prev_pc.value; but that doesn't work very well when fi->next isn't initialized. The attached modifies legacy_get_prev_frame() so that it initializes prev->next var earlier in the frame's creation and thus ensuring that get_frame_pc() can still work. The new frame code doesn't suffer from this problem. committed, Andrew --------------000106050009060506070807 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 5830 2003-04-05 Andrew Cagney * frame.c (get_frame_id): Update comment. (legacy_get_prev_frame): Update comment. * gdbarch.sh: Delete check for EXTRA_FRAME_INFO. * gdbarch.h: Regenerate. * config/sparc/tm-sparc.h (EXTRA_FRAME_INFO): Delete. * frame.h: Delete #ifdef EXTRA_FRAME_INFO code. Index: frame.c =================================================================== RCS file: /cvs/src/src/gdb/frame.c,v retrieving revision 1.96 diff -u -r1.96 frame.c --- frame.c 5 Apr 2003 03:55:59 -0000 1.96 +++ frame.c 5 Apr 2003 15:37:43 -0000 @@ -65,9 +65,7 @@ fi->unwind->this_id (fi->next, &fi->prologue_cache, &fi->id); fi->id_p = 1; /* FIXME: cagney/2002-12-18: Instead of this hack, should only - store the frame ID in PREV_FRAME. Unfortunatly, some - architectures (HP/UX) still reply on EXTRA_FRAME_INFO and, - hence, still poke at the "struct frame_info" object directly. */ + store the frame ID in PREV_FRAME. */ fi->frame = fi->id.base; } return frame_id_build (fi->frame, get_frame_pc (fi)); @@ -1150,9 +1148,7 @@ frame base, in the frame object. */ /* FIXME: cagney/2002-12-18: Instead of this hack, should only - store the frame ID in PREV_FRAME. Unfortunatly, some - architectures (HP/UX) still reply on EXTRA_FRAME_INFO and, - hence, still poke at the "struct frame_info" object directly. */ + store the frame ID in PREV_FRAME. */ /* FIXME: cagney/2003-04-04: Once ->frame is eliminated, this assignment can go. */ prev->frame = prev->id.base; Index: frame.h =================================================================== RCS file: /cvs/src/src/gdb/frame.h,v retrieving revision 1.81 diff -u -r1.81 frame.h --- frame.h 5 Apr 2003 03:56:00 -0000 1.81 +++ frame.h 5 Apr 2003 15:37:44 -0000 @@ -320,7 +320,7 @@ /* Describe the saved registers of a frame. */ -#if defined (EXTRA_FRAME_INFO) || defined (FRAME_FIND_SAVED_REGS) +#if defined (FRAME_FIND_SAVED_REGS) /* XXXX - deprecated */ struct frame_saved_regs { @@ -387,13 +387,6 @@ /* Allocated by frame_saved_regs_zalloc () which is called / initialized by DEPRECATED_FRAME_INIT_SAVED_REGS(). */ CORE_ADDR *saved_regs; /*NUM_REGS + NUM_PSEUDO_REGS*/ - -#ifdef EXTRA_FRAME_INFO - /* XXXX - deprecated */ - /* Anything extra for this structure that may have been defined - in the machine dependent files. */ - EXTRA_FRAME_INFO -#endif /* Anything extra for this structure that may have been defined in the machine dependent files. */ Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.219 diff -u -r1.219 gdbarch.sh --- gdbarch.sh 1 Apr 2003 17:17:27 -0000 1.219 +++ gdbarch.sh 5 Apr 2003 15:37:46 -0000 @@ -821,12 +821,6 @@ converted. */ #if GDB_MULTI_ARCH -#if defined (EXTRA_FRAME_INFO) -#error "EXTRA_FRAME_INFO: replaced by struct frame_extra_info" -#endif -#endif - -#if GDB_MULTI_ARCH #if defined (FRAME_FIND_SAVED_REGS) #error "FRAME_FIND_SAVED_REGS: replaced by DEPRECATED_FRAME_INIT_SAVED_REGS" #endif Index: config/sparc/tm-sparc.h =================================================================== RCS file: /cvs/src/src/gdb/config/sparc/tm-sparc.h,v retrieving revision 1.43 diff -u -r1.43 tm-sparc.h --- config/sparc/tm-sparc.h 26 Mar 2003 22:39:53 -0000 1.43 +++ config/sparc/tm-sparc.h 5 Apr 2003 15:37:46 -0000 @@ -406,53 +406,6 @@ /* DEPRECATED_FRAME_CHAIN takes a frame's nominal address and produces the frame's chain-pointer. */ -/* In the case of the Sun 4, the frame-chain's nominal address - is held in the frame pointer register. - - On the Sun4, the frame (in %fp) is %sp for the previous frame. - From the previous frame's %sp, we can find the previous frame's - %fp: it is in the save area just above the previous frame's %sp. - - If we are setting up an arbitrary frame, we'll need to know where - it ends. Hence the following. This part of the frame cache - structure should be checked before it is assumed that this frame's - bottom is in the stack pointer. - - If there isn't a frame below this one, the bottom of this frame is - in the stack pointer. - - If there is a frame below this one, and the frame pointers are - identical, it's a leaf frame and the bottoms are the same also. - - Otherwise the bottom of this frame is the top of the next frame. - - The bottom field is misnamed, since it might imply that memory from - bottom to frame contains this frame. That need not be true if - stack frames are allocated in different segments (e.g. some on a - stack, some on a heap in the data segment). - - GCC 2.6 and later can generate ``flat register window'' code that - makes frames by explicitly saving those registers that need to be - saved. %i7 is used as the frame pointer, and the frame is laid out - so that flat and non-flat calls can be intermixed freely within a - program. Unfortunately for GDB, this means it must detect and - record the flatness of frames. - - Since the prologue in a flat frame also tells us where fp and pc - have been stashed (the frame is of variable size, so their location - is not fixed), it's convenient to record them in the frame info. */ - -#define EXTRA_FRAME_INFO \ - CORE_ADDR bottom; \ - int in_prologue; \ - int flat; \ - /* Following fields only relevant for flat frames. */ \ - CORE_ADDR pc_addr; \ - CORE_ADDR fp_addr; \ - /* Add this to ->frame to get the value of the stack pointer at the */ \ - /* time of the register saves. */ \ - int sp_offset; - /* We need to override DEPRECATED_GET_SAVED_REGISTER so that we can deal with the way outs change into ins in different frames. */ --------------000106050009060506070807--