From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25034 invoked by alias); 15 Jul 2005 16:03:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24968 invoked by uid 22791); 15 Jul 2005 16:03:16 -0000 Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 15 Jul 2005 16:03:16 +0000 Received: from [10.42.102.103] (STIMPY [10.42.102.103]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 36NKRHP3; Fri, 15 Jul 2005 12:03:15 -0400 Message-ID: <42D7DED5.7020406@qnx.com> Date: Fri, 15 Jul 2005 16:03:00 -0000 From: Kris Warkentin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: "Thomson, Patrick S" CC: gdb@sources.redhat.com Subject: Re: read_structure_type and virtual base types References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00179.txt.bz2 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>: 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: > <2>: 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 : > DW_AT_virtuality : 1 (virtual) > <2>: 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 : > <2>: 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 : > <2>: 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 : > > -- Stay up-to-date on all the QNX news! Register at http://www.qnx.com/news/forms/newsletter.html to receive our newsletter.