Re: read_structure_type and virtual base types

[Kris Warkentin <kewarken at qnx dot 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.