From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1637 invoked by alias); 1 Apr 2003 17:30:53 -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 1619 invoked from network); 1 Apr 2003 17:30:51 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 1 Apr 2003 17:30:51 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3A2412B23 for ; Tue, 1 Apr 2003 12:30:49 -0500 (EST) Message-ID: <3E89CCC9.7040908@redhat.com> Date: Tue, 01 Apr 2003 17:30: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: Re: [RFA] Remove calls to inside_entry_file 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00019.txt.bz2 > > 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. Andrew