From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27078 invoked by alias); 31 Jul 2003 18:20:58 -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 27069 invoked from network); 31 Jul 2003 18:20:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 31 Jul 2003 18:20:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19iI2j-0002LV-Rt; Thu, 31 Jul 2003 14:20:49 -0400 Date: Thu, 31 Jul 2003 18:20:00 -0000 From: Daniel Jacobowitz To: "H. J. Lu" Cc: GDB Subject: Re: gdb can't handle a DIE with both sibling and children Message-ID: <20030731182049.GA20335@nevyn.them.org> Mail-Followup-To: "H. J. Lu" , GDB References: <20030731181355.GA14242@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030731181355.GA14242@lucon.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00373.txt.bz2 On Thu, Jul 31, 2003 at 11:13:55AM -0700, H. J. Lu wrote: > It is entirely possible for a DIE with both sibling and children. But > scan_partial_symbols () has > > /* If the die has a sibling, skip to the sibling. Do not skip > enumeration types, we want to record their enumerators. Do > not skip namespaces, we want to record symbols inside > them. */ > if (pdi.sibling > && pdi.tag != DW_TAG_enumeration_type > && pdi.tag != DW_TAG_namespace) > { > info_ptr = pdi.sibling; > } > else if (pdi.has_children) > { > /* Die has children, but either the optional DW_AT_sibling > attribute is missing or we want to look at them. */ > nesting_level++; > } > > That is we can't handle a DIE with both sibling and children. How > should we fix that? Why don't you be more specific? What problem is it causing, on what input? 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. Probably because once we get to a nested die with no siblings, this little algorithm has no way of finding the parent except for scanning through all the children. This looks like a bug. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer