This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: <incomplete type>


Craig Jeffree <craig.jeffree@preston.net> writes:
> I'm having trouble with GDB reporting an incomplete type...
>
> (gdb) p *acft->posn_->fpi_->seg_->wpApi_[0]
> $1 = <incomplete type>
> (gdb) p *(*acft->posn_->fpi_->seg_->wpApi_)
> $2 = <incomplete type>
>
> 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 {
>     <incomplete type>
> }
>
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]