From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14594 invoked by alias); 2 Sep 2005 00:22:20 -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 14555 invoked by uid 22791); 2 Sep 2005 00:22:02 -0000 Received: from nat-pool-rdu.redhat.com (HELO devserv.devel.redhat.com) (66.187.233.202) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 02 Sep 2005 00:22:02 +0000 Received: from alligator.red-bean.com.redhat.com (vpn26-22.sfbay.redhat.com [172.16.26.22]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j820Lv9W016539; Thu, 1 Sep 2005 20:21:58 -0400 To: Craig Jeffree Cc: gdb@sources.redhat.com Subject: Re: References: <1125021866.10500.71.camel@norman> <1125301769.10500.124.camel@norman> <1125618911.8327.53.camel@norman> From: Jim Blandy Date: Fri, 02 Sep 2005 00:22:00 -0000 In-Reply-To: <1125618911.8327.53.camel@norman> (Craig Jeffree's message of "Fri, 02 Sep 2005 09:55:11 +1000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-09/txt/msg00006.txt.bz2 Craig Jeffree writes: > On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote: >> The leftmost number in is the nesting level of that >> die; so if the entry for the die after the first one you listed starts >> with <2>, then it's a child of the <1> die. There should be >> DW_TAG_member(?) dies. > > Ah, now I can see some sense in these dies. Looking in the actual > executable I can see this... > > <1>: Abbrev Number: 114 (DW_TAG_structure_type) > DW_AT_sibling : > DW_AT_name : (indirect string, offset: 0x4ff824): Waypoint > DW_AT_byte_size : 92 > DW_AT_decl_file : 60 > DW_AT_decl_line : 28 > DW_AT_containing_type: > <2>: Abbrev Number: 54 (DW_TAG_inheritance) > DW_AT_type : > DW_AT_data_member_location: 2 byte block: 23 0 > (DW_OP_plus_uconst: 0) > DW_AT_accessibility: 1 (public) > <2>: Abbrev Number: 56 (DW_TAG_variable) > DW_AT_name : (indirect string, offset: 0x837e8): typeName_ > DW_AT_decl_file : 1 > DW_AT_decl_line : 17 > DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8e402b): > _ZN3Soi8Waypoint9typeName_E > DW_AT_type : > DW_AT_external : 1 > DW_AT_declaration : 1 > <2>: Abbrev Number: 47 (DW_TAG_member) > DW_AT_name : (indirect string, offset: 0x7724ea): wpname_ > DW_AT_decl_file : 60 > DW_AT_decl_line : 84 > DW_AT_type : > DW_AT_data_member_location: 2 byte block: 23 4 > (DW_OP_plus_uconst: 4) > DW_AT_accessibility: 3 (private) > <2>: Abbrev Number: 47 (DW_TAG_member) > DW_AT_name : (indirect string, offset: 0x8e4084): wpll_ > DW_AT_decl_file : 60 > DW_AT_decl_line : 85 > DW_AT_type : > DW_AT_data_member_location: 2 byte block: 23 4c > (DW_OP_plus_uconst: 76) > DW_AT_accessibility: 3 (private) > <2>: Abbrev Number: 48 (DW_TAG_subprogram) > [It then trails off into a long list of methods and their arguments] > > > So, it appears to list the members of Waypoint. Is this enough info for > gdb to not say incomplete type? How can I figure out why gdb is missing > this? When I explicitly try to reference these members of a Waypoint > object gdb says "There is no member named wpll_". Well, we've at least established that 'wpll_' is mentioned in the debug info. If you run GDB on the executable alone, without starting it, what does 'ptype struct Soi::Waypoint' say? (Running the program will load shared libraries and possibly confuse the issue, but GDB should be able to understand the info in the executable without running anything.) >> (I'm apparently wrong about the DW_AT_name being mangled. Does the >> DW_AT_containing_type attribute of the first die point at something >> named "Soi"?) > > The containing type for 'Waypoint' points to a die that appears to > describe Waypoint's base class. That's odd. The Dwarf 3 spec only mentions DW_AT_containing_type in the context of dies describing pointer-to-member types. So the attribute wasn't what I guessed it was, but it also doesn't belong there. > I couldn't find any dies relating to the namespace 'Soi'. I have trouble keeping track of how namespaces are supposed to work in the GNU toolchain; it's changed over time. As I understand it now, if the namespace information were present, it would be a DW_TAG_namespace die, and the DW_TAG_structure_type die would be one of its children. Or, if the type were declared inside the namespace but defined outside it, the definition die might not be a child of a namespace die itself, but it would have a DW_AT_specification attribute that pointed to another die that was. But you're saying there's no "Soi" die at all, so that's all moot. What does 'ptype struct Waypoint' say? (Again, without running the program.)