From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4105 invoked by alias); 26 Aug 2005 19:04: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 3919 invoked by uid 22791); 26 Aug 2005 19:04:00 -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, 26 Aug 2005 19:04:00 +0000 Received: from alligator.red-bean.com.redhat.com (vpn26-18.sfbay.redhat.com [172.16.26.18]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j7QJ3tCq022262; Fri, 26 Aug 2005 15:03:56 -0400 To: Craig Jeffree Cc: gdb@sources.redhat.com Subject: Re: References: <1125021866.10500.71.camel@norman> From: Jim Blandy Date: Fri, 26 Aug 2005 19:04:00 -0000 In-Reply-To: <1125021866.10500.71.camel@norman> (Craig Jeffree's message of "Fri, 26 Aug 2005 12:04:26 +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-08/txt/msg00102.txt.bz2 Craig Jeffree writes: > I'm having trouble with GDB reporting an incomplete type... > > (gdb) p *acft->posn_->fpi_->seg_->wpApi_[0] > $1 = > (gdb) p *(*acft->posn_->fpi_->seg_->wpApi_) > $2 = > > Although the variable I'm printing is deeply nested there is nothing > unusual or complicated about it. There is no templating involved in > this hierarchy of objects. It's simply classes, structs and an array of > a class type. > > I can successfully do the following when stopped at the same breakpoint: > > (gdb) p *acft->posn_->fpi_->seg_->wpApi_ > $3 = (struct Soi::Waypoint *) 0x94d58b8 > > And I also get... > (gdb) ptype *acft->posn_->fpi_->seg_->wpApi_[0] > type = struct Soi::Waypoint { > > } > > What is going on??? >From that, it looks to me like GDB knows that acft->posn_->fpi_->seg_->wpApi_ is a struct Soi::Waypoint **, but it doesn't know what members 'struct Soi::Waypoint' has. This is the way it behaves when it has declarations like this: struct foo; struct foo *ptr; but no definition for 'struct foo' itself. 'incomplete type' is C terminology, not random GDB grousing. The first thing I'd do in this case is check the debug info. That helps you at least decide whether it's GDB's problem, or whether something upstream --- that is, the compiler, assembler, or linker --- is munging things, and GDB's just doing the best it can. 'readelf -wi' dumps Dwarf debugging info in a human-readable form. You can apply it to relocatable object files, executables, and shared libraries. You probably want to apply it to the executable or shared library, since that's fewer steps removed from GDB, but the output will be large. You'll need to search for a DW_TAG_structure debugging information entry ("die") whose DW_AT_name attribute is the mangled form of Soi::Waypoint, and verify that the members are indeed listed there. If you could post that die when you find it, that might be interesting. You can dump the info from a .o file, too. That'd be less to dig through. But then you can't distinguish problems introduced by the linker from GDB screwing up.