From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30214 invoked by alias); 25 Aug 2008 19:54:22 -0000 Received: (qmail 29976 invoked by uid 48); 25 Aug 2008 19:53:13 -0000 Date: Mon, 25 Aug 2008 19:54:00 -0000 Subject: [Bug debug/37237] New: Debug information for virtual destructors omits DW_AT_vtable_elem_location X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "drow at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg01940.txt.bz2 Compile a C++ file containing a class with a virtual destructor. Example from gdb's class2.cc test: struct A { virtual ~A (); int a1; }; A::~A() { a1 = 800; } >>From the DWARF: <2><270>: Abbrev Number: 10 (DW_TAG_subprogram) <271> DW_AT_external : 1 <272> DW_AT_name : ~A <275> DW_AT_decl_file : 1 <276> DW_AT_decl_line : 25 <277> DW_AT_virtuality : 1 (virtual) <278> DW_AT_containing_type: <221> <27c> DW_AT_declaration : 1 There's a DIE for the member function definition which refers to this (DW_AT_specification), too. But neither of them has DW_AT_vtable_elem_location; this is not optional for virtual methods. I assume this is related to the fact that the destructor is cloned (whole object and partial object). That's why it doesn't get a DW_AT_MIPS_linkage_name. I believe there are two vtable slots for the two clones; the most practical thing would be to describe the whole-object version in the DWARF since that's what a debugger will be looking up. I can't think of a better way to handle this; maybe someone else can. -- Summary: Debug information for virtual destructors omits DW_AT_vtable_elem_location Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237