From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 951 invoked by alias); 1 Sep 2005 23:55:47 -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 933 invoked by uid 22791); 1 Sep 2005 23:55:43 -0000 Received: from chfw.preston.net (HELO universe.preston.net) (202.14.89.130) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 01 Sep 2005 23:55:43 +0000 Received: from norman (norman.preston.net [202.14.10.82]) by universe.preston.net (8.11.6/8.11.6) with ESMTP id j81NtB408691; Fri, 2 Sep 2005 09:55:17 +1000 Subject: Re: From: Craig Jeffree To: Jim Blandy Cc: gdb@sources.redhat.com In-Reply-To: References: <1125021866.10500.71.camel@norman> <1125301769.10500.124.camel@norman> Content-Type: text/plain Date: Thu, 01 Sep 2005 23:55:00 -0000 Message-Id: <1125618911.8327.53.camel@norman> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00005.txt.bz2 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_". > (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. I couldn't find any dies relating to the namespace 'Soi'. Thanks for the help so far. Cheers, Craig.