From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1355 invoked by alias); 5 Apr 2003 18:21:33 -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 1344 invoked from network); 5 Apr 2003 18:21:32 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 5 Apr 2003 18:21:32 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3A9E52B23; Sat, 5 Apr 2003 13:21:22 -0500 (EST) Message-ID: <3E8F1EA2.10201@redhat.com> Date: Sat, 05 Apr 2003 18:21: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: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Move legacy prev->next = ... earlier References: <3E8EFCBD.6090401@redhat.com> Content-Type: multipart/mixed; boundary="------------000904070603080306090007" X-SW-Source: 2003-04/txt/msg00089.txt.bz2 This is a multi-part message in MIME format. --------------000904070603080306090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 72 Did I mention that it wasn't my day. Again, the real patch :-/ Andrew --------------000904070603080306090007 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 2217 2003-04-05 Andrew Cagney * frame.c (legacy_get_prev_frame): Link prev to next at the function start. Update comments. Index: frame.c =================================================================== RCS file: /cvs/src/src/gdb/frame.c,v retrieving revision 1.97 diff -u -r1.97 frame.c --- frame.c 5 Apr 2003 15:39:33 -0000 1.97 +++ frame.c 5 Apr 2003 15:42:22 -0000 @@ -1029,10 +1029,7 @@ struct frame_info *prev; int fromleaf; - /* Allocate the new frame but do not wire it in to the frame chain. - Some (bad) code in INIT_FRAME_EXTRA_INFO tries to look along - frame->next to pull some fancy tricks (of course such code is, by - definition, recursive). Try to prevent it. + /* Allocate the new frame. There is no reason to worry about memory leaks, should the remainder of the function fail. The allocated memory will be @@ -1042,6 +1039,17 @@ prev = FRAME_OBSTACK_ZALLOC (struct frame_info); prev->level = this_frame->level + 1; + /* Do not completly wire it in to the frame chain. Some (bad) code + in INIT_FRAME_EXTRA_INFO tries to look along frame->prev to pull + some fancy tricks (of course such code is, by definition, + recursive). + + On the other hand, methods, such as get_frame_pc() and + get_frame_base() rely on being able to walk along the frame + chain. Make certain that at least they work by providing that + link. Of course things manipulating prev can't go back. */ + prev->next = this_frame; + /* NOTE: cagney/2002-11-18: Should have been correctly setting the frame's type here, before anything else, and not last, at the bottom of this function. The various @@ -1155,7 +1163,6 @@ /* Link it in. */ this_frame->prev = prev; - prev->next = this_frame; /* FIXME: cagney/2002-01-19: This call will go away. Instead of initializing extra info, all frames will use the frame_cache @@ -1230,7 +1237,6 @@ /* Link in the already allocated prev frame. */ this_frame->prev = prev; - prev->next = this_frame; deprecated_update_frame_base_hack (prev, address); /* This change should not be needed, FIXME! We should determine --------------000904070603080306090007--