Re: read_structure_type and virtual base types

[Kris Warkentin <kewarken@qnx.com>]

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.