From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25318 invoked by alias); 27 Sep 2011 16:01:16 -0000 Received: (qmail 25309 invoked by uid 22791); 27 Sep 2011 16:01:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=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; Tue, 27 Sep 2011 16:00:56 +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 p8RG0s9T024102 for ; Tue, 27 Sep 2011 18:00:55 +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 2AABDBF6C for ; Tue, 27 Sep 2011 18:00:54 +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 NjJDob9eATH3 for ; Tue, 27 Sep 2011 18:00:53 +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 23371BCC6 for ; Tue, 27 Sep 2011 18:00:53 +0200 (CEST) Subject: Re: Handling of c++ function members From: Joost van der Sluis To: gdb@sourceware.org Date: Tue, 27 Sep 2011 16:01:00 -0000 In-Reply-To: <1317135598.27942.29.camel@feddie.cnoc.lan> References: <1317055596.23338.12.camel@feddie.cnoc.lan> <1317070857.17681.11.camel@feddie.cnoc.lan> <1317135598.27942.29.camel@feddie.cnoc.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1317139253.27942.41.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/msg00126.txt.bz2 On Tue, 2011-09-27 at 16:59 +0200, Joost van der Sluis wrote: > On Mon, 2011-09-26 at 23:00 +0200, Joost van der Sluis wrote: > > 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: > > > > > > Can you be a little more specific, maybe an example? > > > > > > 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. Never mind. I've found a comment in dwarf2read explaining that older gcc versions are indeed using indexes, while 'everything else' doesn't. So I wrote a patch for the Free Pascal Compiler so that it does what 'everything else' does... Regards, Joost van der Sluis.