From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12369 invoked by alias); 26 Sep 2011 21:01:25 -0000 Received: (qmail 12357 invoked by uid 22791); 26 Sep 2011 21:01:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp-vbr11.xs4all.nl (HELO smtp-vbr11.xs4all.nl) (194.109.24.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Sep 2011 21:01:03 +0000 Received: from cnoc.nl.alt001.com (oostvogels.xs4all.nl [83.163.197.192]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id p8QL10Q9082058 for ; Mon, 26 Sep 2011 23:01:00 +0200 (CEST) (envelope-from joost@cnoc.nl) Received: from localhost (localhost.localdomain [127.0.0.1]) by cnoc.nl.alt001.com (Postfix) with ESMTP id 7C0A9BF68 for ; Mon, 26 Sep 2011 23:00:59 +0200 (CEST) Received: from cnoc.nl.alt001.com ([127.0.0.1]) by localhost (cnoc.nl.alt001.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXy68UQ7i5gu for ; Mon, 26 Sep 2011 23:00:58 +0200 (CEST) Received: from [192.168.3.116] (host116.cnoc.intern [192.168.3.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cnoc.nl.alt001.com (Postfix) with ESMTPS id E7773BF16 for ; Mon, 26 Sep 2011 23:00:57 +0200 (CEST) Subject: Re: Handling of c++ function members From: Joost van der Sluis To: gdb@sourceware.org Date: Mon, 26 Sep 2011 21:01:00 -0000 In-Reply-To: References: <1317055596.23338.12.camel@feddie.cnoc.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1317070857.17681.11.camel@feddie.cnoc.lan> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00121.txt.bz2 On Mon, 2011-09-26 at 16:38 -0400, Daniel Jacobowitz wrote: > On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis wrote: > > Hi all, > > > > I've been looking at the code which handles calling c++ function members > > and the Dwarf specifications. Is came to the conclusion that gcc does > > not generate valid Dwarf-debuginfo for those function members, but a > > work-around which is also implemented in gdb, namely in gnu-v2-abi.c. > > > > Is my conclusion right? > > Can you be a little more specific, maybe an example? > > There are definitely oddities in the GCC debug info, but the > workarounds I remember are in the DWARF reader. Problem is that I'm not sure is I read the Dwarf-spec's regarding function members correctly. What I understood is, that DW_AT_vtable_elem_location should contain a Dwarf-block that calculates the location of a pointer in which the location of the function member is stored. But it seems to me that gcc stores the index of the function member within some vtable in DW_AT_vtable_elem_location, instead of the memory address itself. In gnu-v2-abi.c there is some code that 'knows' how this vtable is organized so it is able to calculate the location of the method-pointer. And there are two thing's I'm not sure about: gcc stores DW_AT_containing_type in the debug-info, with the 'parent' entry of the DW_TAG_subprogram entry. To me it looks that this is duplicated information, and not specified in the Dwarf-specs. Secondly I do not understand where the DW_AT_object_pointer is used for? Joost.