read_structure_type and virtual base types
Kris Warkentin
kewarken@qnx.com
Fri Jul 15 16:03:00 GMT 2005
I've actually run into the same problem:
http://sources.redhat.com/ml/gdb/2004-12/msg00074.html
You should probably talk to David Moore since you work for Intel as
well. I ran into him at the gcc summit and he asked me to follow up on
it with him. I've got a PR submitted about this since icc is supposed
to be gcc compatable. It's Intel issue #281637.
For what it's worth, I just worked around it by checking for null and
just skipping the dereference. All that happens is you see a little
less info about the class than you would otherwise.
cheers,
Kris
Thomson, Patrick S wrote:
>Howdy Folks,
>
>I'm attempting to use gdb 6.3 on an executable generated from the
>latest intel c++ compiler (9.0). That particular compiler does not
>generate child DIE information for member functions which are
>declared but not implemented. If the class is a derived class and I
>try to print an instantiated object of that class, gdb crashes.
>
>I tracked what I think is the issue to
>dwarf2read.c::read_structure_type().
>
>At line read_structure_type()+119 we set TYPE_VPTR_BASETYPE(type),
>but only if we have 1 or more member functions (see line
>read_structure_type()+107 for fi.nfnfields test, this field is set at
>line read_structure_type()+94).
>
>Because I have no child DIEs for member functions, TYPE_VPTR_BASETYPE
>remains 0, and I crash later on because this is eventually
>dereferenced. Enough other data remains in the type structure to
>indicate that the class is a derived class, so gdb expects
>TYPE_VPTR_BASETYPE(type) to be set.
>
>Since g++ does output the child die, this isn't generally a problem.
>Ultimately my question is this: Is there a reason why the logic is
>structured the way it is, and what is it? I can fix it easily enough
>in my local copy by moving the closing brace for the
>'if(fi.nfnfields){}' block so that it doesn't encompass the
>DW_AT_containing_type attribute test a few lines later, but I'm not
>sure what the consequences would be.
>
>Thanks!
>Pat Thomson
>Intel Corporation
>
>p.s. example class with associated DWARF DIE
>
>class A : virtual public V{
> int a;
> int aa;
>public:
> void af(int); // declared, not implmented
>};
>
>Has the following DIE
><1><b64>: Abbrev Number: 17 (DW_TAG_class_type)
> DW_AT_decl_line : 11
> DW_AT_decl_column : 7
> DW_AT_decl_file : 1
> DW_AT_accessibility: 1 (public)
> DW_AT_byte_size : 20
> DW_AT_name : A
> DW_AT_containing_type: <b64>
> <2><b70>: Abbrev Number: 18 (DW_TAG_inheritance)
> DW_AT_decl_line : 11
> DW_AT_decl_column : 26
> DW_AT_decl_file : 1
> DW_AT_accessibility: 1 (public)
> DW_AT_data_member_location: 7 byte block: 12 6 10 c 1c 6 22
>(DW_OP_dup; DW_OP_deref; DW_OP_constu: 12; DW_OP_minus; DW_OP_deref;
>DW_OP_plus)
> DW_AT_type : <a75>
> DW_AT_virtuality : 1 (virtual)
> <2><b82>: Abbrev Number: 19 (DW_TAG_member)
> DW_AT_name : _vptr.A
> DW_AT_data_member_location: 2 byte block: 23 0
>(DW_OP_plus_uconst: 0)
> DW_AT_artificial : 1
> DW_AT_type : <baf>
> <2><b93>: Abbrev Number: 3 (DW_TAG_member)
> DW_AT_decl_line : 12
> DW_AT_decl_column : 9
> DW_AT_decl_file : 1
> DW_AT_data_member_location: 2 byte block: 23 4
>(DW_OP_plus_uconst: 4)
> DW_AT_name : a
> DW_AT_type : <ab0>
> <2><ba0>: Abbrev Number: 3 (DW_TAG_member)
> DW_AT_decl_line : 13
> DW_AT_decl_column : 9
> DW_AT_decl_file : 1
> DW_AT_data_member_location: 2 byte block: 23 8
>(DW_OP_plus_uconst: 8)
> DW_AT_name : aa
> DW_AT_type : <ab0>
>
>
--
Stay up-to-date on all the QNX news! Register at
http://www.qnx.com/news/forms/newsletter.html to
receive our newsletter.
More information about the Gdb
mailing list