From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27231 invoked by alias); 31 Jul 2003 19:56:42 -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 27224 invoked from network); 31 Jul 2003 19:56:41 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sources.redhat.com with SMTP; 31 Jul 2003 19:56:41 -0000 Received: from lucon.org ([12.234.88.5]) by comcast.net (sccrmhc13) with ESMTP id <2003073119564101600b3i0re>; Thu, 31 Jul 2003 19:56:41 +0000 Received: by lucon.org (Postfix, from userid 1000) id 383742C4EB; Thu, 31 Jul 2003 19:56:40 +0000 (UTC) Date: Thu, 31 Jul 2003 19:56:00 -0000 From: "H. J. Lu" To: David Carlton Cc: GDB Subject: Re: gdb can't handle a DIE with both sibling and children Message-ID: <20030731195640.GA16048@lucon.org> References: <20030731181355.GA14242@lucon.org> <20030731182049.GA20335@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2003-07/txt/msg00379.txt.bz2 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. H.J. ---- <1><8e>: Abbrev Number: 4 (DW_TAG_subprogram) DW_AT_decl_line : 6 DW_AT_decl_column : 0 DW_AT_decl_file : 1 DW_AT_sibling : <125> DW_AT_accessibility: 1 (public) DW_AT_name : wkinit DW_AT_type : <61> DW_AT_prototyped : 0 DW_AT_high_pc : 0x8049456 134517846 DW_AT_low_pc : 0x8049206 134517254 DW_AT_external : 1 <2>: Abbrev Number: 6 (DW_TAG_entry_point) DW_AT_decl_line : 20 DW_AT_decl_column : 0 DW_AT_decl_file : 1 DW_AT_sibling : DW_AT_name : wkprnt DW_AT_type : <61> DW_AT_low_pc : 0x80492ac 134517420 --- implicit none call wkinit(10) call wkprnt(5) end subroutine wkinit(wksize) implicit none integer wksize, nsize integer jpr integer jprint save jpr jpr = wksize print *, 'On entry, wksize = ',wksize nsize = wksize return entry wkprnt(jprint) print *, 'On entry, jpr = ',jpr print *, 'On entry, jprint = ',jprint if (jprint.eq.2) then jpr = 1-jpr else jpr = jprint endif print *, 'jpr = ',jpr return end