<incomplete type>

<incomplete type>

[Craig Jeffree]

Hi all,

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???

I'm using gdb 6.3 and gcc 3.2.3 with '-g' so it has the default debug
format for x86 Linux.  The OS is Red Hat Enterprise Linux 3.


I'm sorry I can't be much more specific at the moment.  I'm only seeing
this in a huge application (the debug binary is hundreds of megs).  My
attempts to recreate this on a small scale have failed.  I'm at a loss
as to what I should try next.  Any advice on what might be happening and
what I could look at would be greatly appreciated.

My attempts to recreate it in a simpler environment have included:
- recreated the object hierarchy with dummy classes that don't have
seemingly unrelated dependencies.
- trying to reproduce this: http://lists.gnu.org/archive/html/bug-
gdb/2001-09/msg00092.html
- creating a class hierarchy and functions where I can break inside a
compilation unit that was not compiled with the class hierarchy in scope
and then using the class hierarchy in GDB.
- assorted other random smatterings of code that I don't remember the
details of.

All of the above simply result in the debugger understanding exactly
what I'm doing, it never shows an incomplete type.

Cheers,
Craig.

Re: <incomplete type>

[Jim Blandy]

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.

Re: <incomplete type>

[Craig Jeffree]

On Fri, 2005-08-26 at 12:02 -0700, Jim Blandy wrote:
> '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.
> 
I don't think I really understand what I'm looking at here.  In the .o
file I found this:
 <1><ee6b>: Abbrev Number: 113 (DW_TAG_structure_type)
     DW_AT_sibling     : <f3d6>
     DW_AT_name        : (indirect string, offset: 0xd7e3): Waypoint
     DW_AT_byte_size   : 120
     DW_AT_decl_file   : 62
     DW_AT_decl_line   : 33
     DW_AT_containing_type: <1668a>

and in the executable I found this:
 <2><3bb78>: Abbrev Number: 2 (DW_TAG_structure_type)
     DW_AT_sibling     : <3bc2e>
     DW_AT_name        : (indirect string, offset: 0x4ff824): Waypoint
     DW_AT_byte_size   : 24
     DW_AT_decl_file   : 123
     DW_AT_decl_line   : 90


Are these complete dies?  They obviously don't seem to contain any
members or have any references to anything else except for the sibling
which is just an unrelated DW_TAG_structure_type.  Scanning through the
information none of the dies appears to contain anything that look like
members, however the members appear in their own right as separate dies
in the executable but not in the .o file like this:

 <2><a6859d9>: Abbrev Number: 71 (DW_TAG_member)
     DW_AT_name        : (indirect string, offset: 0x7724ea): wpname_
     DW_AT_decl_file   : 158
     DW_AT_decl_line   : 58
     DW_AT_type        : <a667ae0>
     DW_AT_data_member_location: 2 byte block: 23 10
(DW_OP_plus_uconst: 16)
     DW_AT_accessibility: 3     (private)


Am I on the right track, how are the members described in the dies?

Thanks for the help,
Craig.

Re: <incomplete type>

[Jim Blandy]

Craig Jeffree <craig.jeffree@preston.net> writes:
> On Fri, 2005-08-26 at 12:02 -0700, Jim Blandy wrote:
>> '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.
>> 
> I don't think I really understand what I'm looking at here.  In the .o
> file I found this:
>  <1><ee6b>: Abbrev Number: 113 (DW_TAG_structure_type)
>      DW_AT_sibling     : <f3d6>
>      DW_AT_name        : (indirect string, offset: 0xd7e3): Waypoint
>      DW_AT_byte_size   : 120
>      DW_AT_decl_file   : 62
>      DW_AT_decl_line   : 33
>      DW_AT_containing_type: <1668a>
>
> and in the executable I found this:
>  <2><3bb78>: Abbrev Number: 2 (DW_TAG_structure_type)
>      DW_AT_sibling     : <3bc2e>
>      DW_AT_name        : (indirect string, offset: 0x4ff824): Waypoint
>      DW_AT_byte_size   : 24
>      DW_AT_decl_file   : 123
>      DW_AT_decl_line   : 90
>
>
> Are these complete dies?

The leftmost number in <angle brackets> 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.

(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"?)

Re: <incomplete type>

[Craig Jeffree]

On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
> The leftmost number in <angle brackets> 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><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
     DW_AT_sibling     : <c74aadf>
     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: <c74b7e1>
 <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
     DW_AT_type        : <c74abb4>
     DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
     DW_AT_accessibility: 1     (public)
 <2><c74a6a1>: 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        : <c74b7af>
     DW_AT_external    : 1
     DW_AT_declaration : 1
 <2><c74a6b2>: 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        : <c74b7b4>
     DW_AT_data_member_location: 2 byte block: 23 4
(DW_OP_plus_uconst: 4)
     DW_AT_accessibility: 3     (private)
 <2><c74a6c1>: 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        : <c748414>
     DW_AT_data_member_location: 2 byte block: 23 4c
(DW_OP_plus_uconst: 76)
     DW_AT_accessibility: 3     (private)
 <2><c74a6d0>: 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.

Re: <incomplete type>

[Jim Blandy]

Craig Jeffree <craig.jeffree@preston.net> writes:
> On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
>> The leftmost number in <angle brackets> 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><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
>      DW_AT_sibling     : <c74aadf>
>      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: <c74b7e1>
>  <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
>      DW_AT_type        : <c74abb4>
>      DW_AT_data_member_location: 2 byte block: 23 0
> (DW_OP_plus_uconst: 0)
>      DW_AT_accessibility: 1     (public)
>  <2><c74a6a1>: 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        : <c74b7af>
>      DW_AT_external    : 1
>      DW_AT_declaration : 1
>  <2><c74a6b2>: 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        : <c74b7b4>
>      DW_AT_data_member_location: 2 byte block: 23 4
> (DW_OP_plus_uconst: 4)
>      DW_AT_accessibility: 3     (private)
>  <2><c74a6c1>: 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        : <c748414>
>      DW_AT_data_member_location: 2 byte block: 23 4c
> (DW_OP_plus_uconst: 76)
>      DW_AT_accessibility: 3     (private)
>  <2><c74a6d0>: 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.)

Re: <incomplete type>

[Craig Jeffree]

On Thu, 2005-09-01 at 17:20 -0700, Jim Blandy wrote:
> 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.)

  (gdb) ptype struct Soi::Waypoint
  No struct type named Soi.
[That's right, Soi's a namespace, but why doesn't it recongnise
Soi::Waypoint as a struct?]

  (gdb) ptype Soi::Waypoint
  type = namespace Soi::Waypoint
[Waypoint isn't a namespace though, its a class!]

  (gdb) ptype Soi
  type = namespace Soi

  (gdb) ptype struct Waypoint
  Internal: global symbol `Waypoint' found in SoiWaypoint.C psymtab but
not in symtab.
  Waypoint may be an inlined function, or may be a template function
  (if a template, try specifying an instantiation: Waypoint<type>).
[Waypoint isn't a template, it is a fairly normal class]

  (gdb) ptype Soi::Waypoint::wpll_
  type = class AdmLatLong { [long class decl] } ( Soi::Waypoint::&)

  (gdb) ptype Soi::Waypoint::wpname_
  type = char ( Soi::Waypoint::&)[72]


> 
> >> (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 should have also mentioned that the containing type points to the base
class at the top of the hierarchy, not the class mentioned in Waypoint's
declaration, but instead the class mentioned in that class's
declaration.

> 
> 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.

What about dwarf 2?  I'm using gcc 3.2.3 and it's doco seems to refer to
dwarf 2 rather than 3?  What versions does GDB work with?  Should I be
able to expect GDB 6.3 to work with 3.2.3 as well as it does with 3.4.x?

> > 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.

Maybe not.  Looking in the commands I've quoted at the top of this post
GDB does understand that Soi is a namespace, but readelf doesn't list
anything that describes this namespace.
> 
> What does 'ptype struct Waypoint' say?  (Again, without running the
> program.)

  (gdb) ptype struct Waypoint
  Internal: global symbol `Waypoint' found in SoiWaypoint.C psymtab but
not in symtab.
  Waypoint may be an inlined function, or may be a template function
  (if a template, try specifying an instantiation: Waypoint<type>).
[Waypoint isn't a template, it is a fairly normal class]

Re: <incomplete type>

[Craig Jeffree]

On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
> The leftmost number in <angle brackets> 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><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
     DW_AT_sibling     : <c74aadf>
     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: <c74b7e1>
 <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
     DW_AT_type        : <c74abb4>
     DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
     DW_AT_accessibility: 1     (public)
 <2><c74a6a1>: 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        : <c74b7af>
     DW_AT_external    : 1
     DW_AT_declaration : 1
 <2><c74a6b2>: 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        : <c74b7b4>
     DW_AT_data_member_location: 2 byte block: 23 4
(DW_OP_plus_uconst: 4)
     DW_AT_accessibility: 3     (private)
 <2><c74a6c1>: 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        : <c748414>
     DW_AT_data_member_location: 2 byte block: 23 4c
(DW_OP_plus_uconst: 76)
     DW_AT_accessibility: 3     (private)
 <2><c74a6d0>: 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.

Re: <incomplete type>

[Daniel Jacobowitz]

On Fri, Sep 02, 2005 at 11:49:51AM +1000, Craig Jeffree wrote:
> On Thu, 2005-09-01 at 17:20 -0700, Jim Blandy wrote:
> > 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.)
> 
>   (gdb) ptype struct Soi::Waypoint
>   No struct type named Soi.
> [That's right, Soi's a namespace, but why doesn't it recongnise
> Soi::Waypoint as a struct?]

Craig, could you try this using gdb -readnow?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: <incomplete type>

[Craig Jeffree]

On Fri, 2005-09-02 at 09:16 -0400, Daniel Jacobowitz wrote:
> >   (gdb) ptype struct Soi::Waypoint
> >   No struct type named Soi.
> > [That's right, Soi's a namespace, but why doesn't it recongnise
> > Soi::Waypoint as a struct?]
> 
> Craig, could you try this using gdb -readnow?
> 

Good work Daniel.  It works when I do this.  Thank-you.

Okay, so what's the difference?  I know in my application the specific
example I'm testing with uses a name ('Waypoint') which exists in
different forms throughout the application (there are a few different
namespaces that have a class or something named 'Waypoint').  Is this
the cause, does gdb not know which one to look at if they aren't all
loaded?  That doesn't seem right, it should still know how to find the
right one shouldn't it?

Is there any other way to work around this?  I ask because my
application is huge and gdb takes about 15 minutes to start up when I
use the '-readnow' flag.  Once started gdb's virtual memory usage is
about 2gb.

Cheers,
Craig.

Re: <incomplete type>

[Daniel Jacobowitz]

On Mon, Sep 05, 2005 at 05:33:10PM +1000, Craig Jeffree wrote:
> On Fri, 2005-09-02 at 09:16 -0400, Daniel Jacobowitz wrote:
> > >   (gdb) ptype struct Soi::Waypoint
> > >   No struct type named Soi.
> > > [That's right, Soi's a namespace, but why doesn't it recongnise
> > > Soi::Waypoint as a struct?]
> > 
> > Craig, could you try this using gdb -readnow?
> > 
> 
> Good work Daniel.  It works when I do this.  Thank-you.

That means it's almost certainly a bug in GDB.

> Okay, so what's the difference?  I know in my application the specific
> example I'm testing with uses a name ('Waypoint') which exists in
> different forms throughout the application (there are a few different
> namespaces that have a class or something named 'Waypoint').  Is this
> the cause, does gdb not know which one to look at if they aren't all
> loaded?  That doesn't seem right, it should still know how to find the
> right one shouldn't it?

Should, but this code is very tricky, to say the least.  And it's
sensitive to the exact version of the compiler in use.  Remind me, are
you using CVS HEAD?  And, I don't suppose you've got a smaller
testcase?

Failing that, could you post the readelf output for the entire
compilation unit containing Soi::Waypoint?  From the compilation unit
header all the way down to the next one.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: <incomplete type>

[Craig Jeffree]

On Mon, 2005-09-05 at 10:00 -0400, Daniel Jacobowitz wrote:
> Should, but this code is very tricky, to say the least.  And it's
> sensitive to the exact version of the compiler in use.  Remind me, are
> you using CVS HEAD?  And, I don't suppose you've got a smaller
> testcase?

I'm using GDB 6.3 on RHEL4 with gcc 3.2.3.  And no, I have failed in all
my attempts to make a small testcase.

> 
> Failing that, could you post the readelf output for the entire
> compilation unit containing Soi::Waypoint?  From the compilation unit
> header all the way down to the next one.
> 

Yes.  However, Daniel, Jim, I will send this to you privately as my
company wishes to keep it off the public archives.  I will send it in a
separate email.

Thanks for helping me through this.

Cheers,
Craig.

Re: <incomplete type>

[Daniel Jacobowitz]

On Tue, Sep 06, 2005 at 05:14:01PM +1000, Craig Jeffree wrote:
> > Failing that, could you post the readelf output for the entire
> > compilation unit containing Soi::Waypoint?  From the compilation unit
> > header all the way down to the next one.
> > 
> 
> Yes.  However, Daniel, Jim, I will send this to you privately as my
> company wishes to keep it off the public archives.  I will send it in a
> separate email.
> 
> Thanks for helping me through this.

First of all, I note that you're using GCC 3.2.3.  That version didn't
output proper DWARF debugging information for namespaces, so it
triggers a different path through GDB (that involves a lot more
guessing).

Here's what I think is happening.

There's considerable code in GDB to guess the namespace of a structure
when this problem is encountered.  But that code relies upon the
mangled names of member functions of the type.  Probably it is
successfully triggering for the _definition_ of the type, but in some
other compilation unit (the one with the reference that shows up as
incomplete), the DIE containing the declaration of Soi::Waypoint
doesn't have enough information.  So the best GDB can come up with is
"Waypoint".  Then it looks, and doesn't find Waypoint - the only
definition was Soi::Waypoint, with a namespace qualifier.  So, no
match.

There's just nothing GDB can do, if that's what's happening.  You may
be able to find a GCC patch in the archives of gcc-patches or
gdb-patches to add DW_AT_namespace support to GCC 3.2.3, if rebuilding
the compiler is an option.  Otherwise you're stuck until you upgrade
GCC.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: <incomplete type>

[Daniel Jacobowitz]

On Thu, Sep 01, 2005 at 05:20:51PM -0700, Jim Blandy wrote:
> >> (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.

This is a GNUism, and a very bad one nowadays, especially since GDB
relies on it.  I have queued up behind my other pending DWARF patches
some fixes for that.  For GCC, DW_AT_containing_type is the type
containing the class's vtable pointer.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: <incomplete type>

[Craig Jeffree]

On Sun, 2005-09-11 at 21:34 -0400, Daniel Jacobowitz wrote:
> Here's what I think is happening.
> 
> There's considerable code in GDB to guess the namespace of a structure
> when this problem is encountered.  But that code relies upon the
> mangled names of member functions of the type.  Probably it is
> successfully triggering for the _definition_ of the type, but in some
> other compilation unit (the one with the reference that shows up as
> incomplete), the DIE containing the declaration of Soi::Waypoint
> doesn't have enough information.  So the best GDB can come up with is
> "Waypoint".  Then it looks, and doesn't find Waypoint - the only
> definition was Soi::Waypoint, with a namespace qualifier.  So, no
> match.

Thanks for looking at this for me Daniel.  I assume the easiest way to
check if this hypothesis is correct would be for me to track down the
patch you mention below so I will go away and do that.

> 
> There's just nothing GDB can do, if that's what's happening.  You may
> be able to find a GCC patch in the archives of gcc-patches or
> gdb-patches to add DW_AT_namespace support to GCC 3.2.3, if rebuilding
> the compiler is an option.  Otherwise you're stuck until you upgrade
> GCC.
> 
> 

Re: <incomplete type>

[Craig Jeffree]

On Thu, 2005-09-15 at 15:11 +1000, Craig Jeffree wrote:
> On Sun, 2005-09-11 at 21:34 -0400, Daniel Jacobowitz wrote:
> > Here's what I think is happening.
> > 
> > There's considerable code in GDB to guess the namespace of a structure
> > when this problem is encountered.  But that code relies upon the
> > mangled names of member functions of the type.  Probably it is
> > successfully triggering for the _definition_ of the type, but in some
> > other compilation unit (the one with the reference that shows up as
> > incomplete), the DIE containing the declaration of Soi::Waypoint
> > doesn't have enough information.  So the best GDB can come up with is
> > "Waypoint".  Then it looks, and doesn't find Waypoint - the only
> > definition was Soi::Waypoint, with a namespace qualifier.  So, no
> > match.
> > 
> > There's just nothing GDB can do, if that's what's happening.  You may
> > be able to find a GCC patch in the archives of gcc-patches or
> > gdb-patches to add DW_AT_namespace support to GCC 3.2.3, if rebuilding
> > the compiler is an option.  Otherwise you're stuck until you upgrade
> > GCC.
> > 
> > 

Just for the record I found the patch to dwarf2out.c (rev 1.466) and
applied it to gcc 3.2.3 (with a little bit of massaging).  I then used
this patched compiler to build my app and was able to resolve the
troubled incomplete type in GDB.  So in short, Daniel was spot on
regarding what occured inside GDB and this issue is resolved when using
the namespace patch mentioned above which comes in the stock 3.4.x
version of gcc.

Thanks for helping.
Craig

"Incomplete Type"

[lin q]

Hi,
  This is a question about DDD, hopefully it is not so off-topic in this 
group.

  I am using DDD 3.3.1 with gdb 6.3 and when I use "Display" command to 
display some complex type data value, it always shows as "incomplete type".

I am pretty sure that all the code are compiled with -g option and in 
starting DDD, I define all the source file paths through --directory option.

Do you know what might go wrong?

Thanks a lot.

_________________________________________________________________
DonÂ’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/