From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20275 invoked by alias); 19 Feb 2003 18:52:09 -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 20267 invoked from network); 19 Feb 2003 18:52:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 19 Feb 2003 18:52:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18lbDK-0006wn-00; Wed, 19 Feb 2003 14:53:11 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lZK6-000302-00; Wed, 19 Feb 2003 13:52:02 -0500 Date: Wed, 19 Feb 2003 18:52:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: GDB Patches Subject: Re: [patch/rfc] Add a sentinel frame Message-ID: <20030219185202.GA11371@nevyn.them.org> Mail-Followup-To: Andrew Cagney , GDB Patches References: <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> <3E53CFB8.8070201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E53CFB8.8070201@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00430.txt.bz2 On Wed, Feb 19, 2003 at 01:40:56PM -0500, Andrew Cagney wrote: > >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(). Offhand, we do _not_ pass in the frame base - we base in the base for the next frame. get_prev_frame makes the same get_frame_pc call. You've lost the call to inside_entry_func. Why? You've changed the inside_entry_file check to check the PC for the next frame instead of the forthcoming frame, which is not at all the same thing. Why? You've lost the hook for an architecture-specific FRAME_CHAIN_VALID_P. I've asked you about this before and I still don't understand where you want that logic to go. The impression I've gotten is that you want it to vanish, and that doesn't make any sense. I'm not sure why the new order is better. Duplicating the code has just made it harder for me to spot what I consider under-explained changes in the logic. > 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. I have, at length. It hasn't been helping. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer