From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22778 invoked by alias); 13 Jul 2005 20:04:46 -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 22762 invoked by uid 22791); 13 Jul 2005 20:04:42 -0000 Received: from petasus.ch.intel.com (HELO petasus.ch.intel.com) (143.182.124.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 13 Jul 2005 20:04:42 +0000 Received: from azsmsxvs041.ch.intel.com (azsmsxvs041.ch.intel.com [143.182.252.55]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.10/d: small-solo.mc,v 1.2 2004/09/17 18:05:04 root Exp $) with SMTP id j6DK236m030632 for ; Wed, 13 Jul 2005 20:02:07 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs041.ch.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005071313043620233 for ; Wed, 13 Jul 2005 13:04:36 -0700 Received: from azsmsx407.amr.corp.intel.com ([10.2.161.33]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 13:04:36 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: read_structure_type and virtual base types Date: Wed, 13 Jul 2005 20:04:00 -0000 Message-ID: From: "Thomson, Patrick S" To: X-SW-Source: 2005-07/txt/msg00156.txt.bz2 Howdy Folks, I'm attempting to use gdb 6.3 on an executable generated from the=20 latest intel c++ compiler (9.0). That particular compiler does not=20 generate child DIE information for member functions which are=20 declared but not implemented. If the class is a derived class and I=20 try to print an instantiated object of that class, gdb crashes. I tracked what I think is the issue to=20 dwarf2read.c::read_structure_type(). At line read_structure_type()+119 we set TYPE_VPTR_BASETYPE(type),=20 but only if we have 1 or more member functions (see line=20 read_structure_type()+107 for fi.nfnfields test, this field is set at=20 line read_structure_type()+94).=20 Because I have no child DIEs for member functions, TYPE_VPTR_BASETYPE=20 remains 0, and I crash later on because this is eventually=20 dereferenced. Enough other data remains in the type structure to=20 indicate that the class is a derived class, so gdb expects=20 TYPE_VPTR_BASETYPE(type) to be set. Since g++ does output the child die, this isn't generally a problem.=20 Ultimately my question is this: Is there a reason why the logic is=20 structured the way it is, and what is it? I can fix it easily enough=20 in my local copy by moving the closing brace for the=20 'if(fi.nfnfields){}' block so that it doesn't encompass the=20 DW_AT_containing_type attribute test a few lines later, but I'm not=20 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=09 DW_AT_decl_column : 7=09 DW_AT_decl_file : 1=09 DW_AT_accessibility: 1 (public) DW_AT_byte_size : 20=09 DW_AT_name : A=09 DW_AT_containing_type: =09 <2>: Abbrev Number: 18 (DW_TAG_inheritance) DW_AT_decl_line : 11=09 DW_AT_decl_column : 26=09 DW_AT_decl_file : 1=09 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 : =09 DW_AT_virtuality : 1 (virtual) <2>: Abbrev Number: 19 (DW_TAG_member) DW_AT_name : _vptr.A=09 DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0) DW_AT_artificial : 1=09 DW_AT_type : =09 <2>: Abbrev Number: 3 (DW_TAG_member) DW_AT_decl_line : 12=09 DW_AT_decl_column : 9=09 DW_AT_decl_file : 1=09 DW_AT_data_member_location: 2 byte block: 23 4 (DW_OP_plus_uconst: 4) DW_AT_name : a=09 DW_AT_type : =09 <2>: Abbrev Number: 3 (DW_TAG_member) DW_AT_decl_line : 13=09 DW_AT_decl_column : 9=09 DW_AT_decl_file : 1=09 DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8) DW_AT_name : aa=09 DW_AT_type :