From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32612 invoked by alias); 31 Jul 2003 20:02:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32542 invoked from network); 31 Jul 2003 20:02:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 31 Jul 2003 20:02:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19iJct-0004dj-FO; Thu, 31 Jul 2003 16:02:15 -0400 Date: Thu, 31 Jul 2003 20:02:00 -0000 From: Daniel Jacobowitz To: "H. J. Lu" Cc: David Carlton , GDB Subject: Re: gdb can't handle a DIE with both sibling and children Message-ID: <20030731200215.GA17805@nevyn.them.org> Mail-Followup-To: "H. J. Lu" , David Carlton , GDB References: <20030731181355.GA14242@lucon.org> <20030731182049.GA20335@nevyn.them.org> <20030731195640.GA16048@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030731195640.GA16048@lucon.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00380.txt.bz2 On Thu, Jul 31, 2003 at 12:56:40PM -0700, H. J. Lu wrote: > On Thu, Jul 31, 2003 at 12:36:15PM -0700, David Carlton wrote: > > On Thu, 31 Jul 2003 14:20:49 -0400, Daniel Jacobowitz said: > > > > > It seems quite clear that the code above is deliberately only > > > visiting children of DW_TAG_enumeration_type and DW_TAG_namespace, > > > since those are the only things whose children it needs to visit. I > > > don't know why it was written that way, which does seem strange; I > > > imagine it does a lot of useless recursing. > > > > It's not written in the clearest fashion. I have this cleaned up on > > my branch to some extent, in a matter which, I hope, makes it clearer > > that, normally, we always want to skip children (whether or not the > > DIE happens to have a DW_AT_sibling attached to it): after all, most > > of the information contained in children is information that we don't > > need until a full symtab has been loaded. My rewrite then forks off > > the special cases for which we actually do want to look at children > > into their own special functions; maybe H.J. could add one for > > subprograms that looks for entry point tags. (Assuming, of course, > > that it really is important for the partial symbol table to know about > > entry point tags, not just the full symbol table.) > > > > I don't know for sure how DW_TAG_entry_point works. It seems to me > that DW_TAG_entry_point should inherit DW_AT_accessibility and > DW_AT_high_pc from its parent. Certainly not high_pc. Its _bounds_ are the bounds of its parent; the entry point is only specific PC that gets jumped to. I don't know about DW_AT_accessibility. You'd have to ask someone who knows more about Fortran than I do. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer