From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-39870-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10808 invoked by alias); 30 Sep 2011 15:53:32 -0000
Received: (qmail 10795 invoked by uid 22791); 30 Sep 2011 15:53:30 -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; Fri, 30 Sep 2011 15:53:11 +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 p8UFr82x039892;	Fri, 30 Sep 2011 17:53:08 +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 3DFC9BF45;	Fri, 30 Sep 2011 17:53:08 +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 tCClwLJllcwg; Fri, 30 Sep 2011 17:53:06 +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 75DB6BCCD;	Fri, 30 Sep 2011 17:53:06 +0200 (CEST)
Subject: Re: Handling of c++ function members
From: Joost van der Sluis <joost@cnoc.nl>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sourceware.org
Date: Fri, 30 Sep 2011 15:53:00 -0000
In-Reply-To: <CAN9gPaHjTjxDZ+zhMZ3zR0-jb_Xaeh7VH1EQHRewUaELnPfQGw@mail.gmail.com>
References: <1317055596.23338.12.camel@feddie.cnoc.lan>	 <CAN9gPaE0K+z-8H5NyHmHg2KcYz2QEAHOy=eXC28bva0-zD4xhg@mail.gmail.com>	 <1317070857.17681.11.camel@feddie.cnoc.lan>	 <1317135598.27942.29.camel@feddie.cnoc.lan>	 <CAN9gPaHjTjxDZ+zhMZ3zR0-jb_Xaeh7VH1EQHRewUaELnPfQGw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <1317397986.24685.82.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: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2011-09/txt/msg00140.txt.bz2

On Fri, 2011-09-30 at 10:42 -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 27, 2011 at 10:59 AM, Joost van der Sluis <joost@cnoc.nl> wrote:
> >> 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.
> 
> Your final conclusion is right - I thought the workaround was
> contained to the dwarf reader, but maybe not.

Yes, I've found it.

> Are you actually passing through gnu-v2-abi.c?  Everythong ought to be
> on the v3 abi unless this is another FPC quirk...

Well, I've used the virtual-function example for c++ from wikipedia,
compiled it  (gcc 4.6.1) on Fedora 15 and loaded it into gdb. Stepping
though gdb it indeed passed gnu-v2-abi.c. So fpc wasn't involved at all.

Regards,

Joost.