From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15113 invoked by alias); 1 Apr 2003 17:03:29 -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 15105 invoked from network); 1 Apr 2003 17:03:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Apr 2003 17:03:29 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h31H3RQ23567 for ; Tue, 1 Apr 2003 12:03:27 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h31H3OQ24962 for ; Tue, 1 Apr 2003 12:03:25 -0500 Received: from cygbert.vinschen.de (vpn50-16.rdu.redhat.com [172.16.50.16]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h31H3I520429 for ; Tue, 1 Apr 2003 09:03:19 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h31H37d13600 for gdb-patches@sources.redhat.com; Tue, 1 Apr 2003 19:03:07 +0200 Date: Tue, 01 Apr 2003 17:03:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Remove calls to inside_entry_file Message-ID: <20030401170307.GD18138@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E89BFE4.7020500@redhat.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-04/txt/msg00017.txt.bz2 On Tue, Apr 01, 2003 at 11:35:48AM -0500, Andrew Cagney wrote: > > >>Andrew > >> > >>PS: Patch? > > The revised change you committed to frame.c? 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: >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. The patch to frame.c looks like this now: Index: frame.c =================================================================== RCS file: /cvs/src/src/gdb/frame.c,v retrieving revision 1.91 retrieving revision 1.92 diff -u -p -r1.91 -r1.92 --- frame.c 31 Mar 2003 19:01:19 -0000 1.91 +++ frame.c 1 Apr 2003 15:26:08 -0000 1.92 @@ -1428,6 +1428,7 @@ get_prev_frame (struct frame_info *this_ return this_frame->prev; this_frame->prev_p = 1; +#if 0 /* If we're inside the entry file, it isn't valid. Don't apply this test to a dummy frame - dummy frame PC's typically land in the entry file. Don't apply this test to the sentinel frame. @@ -1439,6 +1440,15 @@ get_prev_frame (struct frame_info *this_ /* NOTE: cagney/2003-01-10: If there is a way of disabling this test then it should probably be moved to before the ->prev_p test, above. */ + /* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call to + inside_entry_file destroys a meaningful backtrace under some + conditions. E. g. the backtrace tests in the asm-source testcase + are broken for some targets. In this test the functions are all + implemented as part of one file and the testcase is not necessarily + linked with a start file (depending on the target). What happens is, + that the first frame is printed normaly and following frames are + treated as being inside the enttry file then. This way, only the + #0 frame is printed in the backtrace output. */ if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0 && inside_entry_file (get_frame_pc (this_frame))) { @@ -1447,6 +1457,7 @@ get_prev_frame (struct frame_info *this_ "Outermost frame - inside entry file\n"); return NULL; } +#endif /* If we're already inside the entry function for the main objfile, then it isn't valid. Don't apply this test to a dummy frame - Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com