From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19278 invoked by alias); 1 Apr 2003 19:58:42 -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 19246 invoked from network); 1 Apr 2003 19:58:40 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 1 Apr 2003 19:58:40 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 190Ru3-0006fG-00 for ; Tue, 01 Apr 2003 13:58:39 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 190Rtw-0002ew-00 for ; Tue, 01 Apr 2003 14:58:32 -0500 Date: Tue, 01 Apr 2003 19:58:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Remove calls to inside_entry_file Message-ID: <20030401195832.GA10202@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030327113330.GH23762@cygbert.vinschen.de> <3E84E8B4.7000502@redhat.com> <20030401153125.GY18138@cygbert.vinschen.de> <3E89B2AA.5060304@redhat.com> <20030401161824.GA18138@cygbert.vinschen.de> <3E89BFE4.7020500@redhat.com> <20030401170307.GD18138@cygbert.vinschen.de> <3E89CCC9.7040908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E89CCC9.7040908@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00022.txt.bz2 On Tue, Apr 01, 2003 at 12:30:49PM -0500, Andrew Cagney wrote: > > > >Oh, you wrote "Consider that approved" so I didn't thought I'd have > >to send it again to gdb-patches. However, what about the important > >part of my posting: > > Yes, just please always post changes. > > >>I've checked in the frame.c patch but still, I don't understand this > >>decision. So called out-of-date targets can easily add the > >>inside_entry_file() call to their frame_chain_valid() implementation > >>so removing this call from blockframe.c does not necessarily break > >>them. Keeping this call in blockframe.c on the other hand breaks > >>some targets for which this call is plainly wrong. So the logic would > >>imply to remove the call in favour of *all* targets able to run correctly. > > Per my previous comment, I'd prefer to not touch the old code at all - > let it die. Mark, I'll note, already has i386 replacement code in waiting. > > The other thing to do is to ask DanielJ if he knows anything more about > that specific case. Nope. It was there before I put my hands on it; it seems suspicious to me though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer