From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8857 invoked by alias); 19 Feb 2003 18:36:12 -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 8835 invoked from network); 19 Feb 2003 18:36:11 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 18:36:11 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E63F22E96; Wed, 19 Feb 2003 13:40:56 -0500 (EST) Message-ID: <3E53CFB8.8070201@redhat.com> Date: Wed, 19 Feb 2003 18:36:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: GDB Patches Subject: Re: [patch/rfc] Add a sentinel frame References: <3E48378E.6090007@suse.cz> <3E492953.8010001@redhat.com> <3E52173B.1030800@suse.cz> <3E538770.6070209@redhat.com> <20030219140441.GA20537@nevyn.them.org> <3E53B61C.2050807@redhat.com> <20030219165623.GA7961@nevyn.them.org> <3E53BBCB.2010003@redhat.com> <20030219171700.GA8736@nevyn.them.org> <3E53C416.30809@redhat.com> <20030219175654.GA10010@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00428.txt.bz2 > On Wed, Feb 19, 2003 at 12:51:18PM -0500, Andrew Cagney wrote: > >> > >> >>When you first committed that stuff, I warned you that would happen :-) >> >>The above test handled differently. > >> > >> > >> >Hey, you can't blame me for this bit. I didn't add that check for >> >DEPRECATED_PC_IN_CALL_DUMMY, it was already there in >> >generic_frame_chain_valid. > >> >> I'm refering to frame_chain_valid(), a small part of which you changed. >> The useful bits (your changes) were copied to the rewritten >> get_prev_frame. When frame_chain_valid() is deleted, that duplication >> will go away. To see what's wrong with frame_chain_valid() see >> legacy_get_prev_frame. > > > I'm slow. Could you explain the problem? There's a comment about > things being deduced there which is no longer true, and a comment about > leaves of main that I can't make heads nor tails of but I don't think > it applies. Where does one start? it calls pc_unwind; it calls get_frame_pc; it calls get_frame_base yet we passed in the frame base; it does tests in the wrong order, carefully compare it to get_prev_frame; the lack of frame-id; the fact that, on the sparc, the fp that is passed in was bogus; knowing that all the function was ment to the general confusion over unwinding the pc or fp first; knowing that frame_chain_valid() started out as an equivalent to frame_id_p(). Contrast that to the new get_prev_frame() were everything is handled at the one level. As I said, to understand this, you're really going to have to study the code. Andrew