From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20603 invoked by alias); 2 Apr 2003 16:36:10 -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 20596 invoked from network); 2 Apr 2003 16:36:10 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 2 Apr 2003 16:36:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F3ED22B23 for ; Wed, 2 Apr 2003 11:36:08 -0500 (EST) Message-ID: <3E8B1178.6050605@redhat.com> Date: Wed, 02 Apr 2003 16:36: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> <3E89CCC9.7040908@redhat.com> <20030401195832.GA10202@nevyn.them.org> <20030402092741.GA26480@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00031.txt.bz2 >> > 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. > > > What do you mean by "suspicious"? You did already comment on this in > blockframe.c so I assume you had rather mixed feelings about this call. > > I don't see a reason not to change this. It will take some time to > move all targets to the new scheme. Why should some of the not converted > targets remain broken due to an obvious bug? I'm beginning to think that reverting some of the original change: RFC: Mostly kill FRAME_CHAIN_VALID, add user knob http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html might be the best option. What about moving this: > + > + /* If the architecture has a custom FRAME_CHAIN_VALID, call it now. */ > + if (FRAME_CHAIN_VALID_P ()) > + return FRAME_CHAIN_VALID (fp, fi); to before this: + /* If we're already inside the entry function for the main objfile, then it + isn't valid. */ + if (inside_entry_func (get_frame_pc (fi))) + return 0; + + /* If we're inside the entry file, it isn't valid. */ + /* NOTE/drow 2002-12-25: should there be a way to disable this check? It + assumes a single small entry file, and the way some debug readers (e.g. + dbxread) figure out which object is the entry file is somewhat hokey. */ + if (inside_entry_file (frame_pc_unwind (fi))) + return 0; + + /* If we want backtraces to stop at main, and we're inside main, then it + isn't valid. */ + if (!backtrace_below_main && inside_main_func (get_frame_pc (fi))) + return 0; That more closely resembles the original behavior. Andrew