From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21155 invoked by alias); 2 Oct 2011 13:51:15 -0000 Received: (qmail 21147 invoked by uid 22791); 2 Oct 2011 13:51: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-vbr1.xs4all.nl (HELO smtp-vbr1.xs4all.nl) (194.109.24.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 02 Oct 2011 13:50:51 +0000 Received: from cnoc.nl.alt001.com (oostvogels.xs4all.nl [83.163.197.192]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id p92Don1j062536; Sun, 2 Oct 2011 15:50:49 +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 15F0ABF29; Sun, 2 Oct 2011 15:50:49 +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 GpvklahJpW2u; Sun, 2 Oct 2011 15:50:47 +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 BBC7CBF20; Sun, 2 Oct 2011 15:50:47 +0200 (CEST) Subject: Re: Handling of c++ function members From: Joost van der Sluis To: Daniel Jacobowitz Cc: gdb@sourceware.org Date: Sun, 02 Oct 2011 13:51:00 -0000 In-Reply-To: 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="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1317563447.11265.19.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-10/txt/msg00002.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 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. Indeed. The workaround in the dwarf-reader is when it encounters a Dwarf-block for a DW_AT_vtable_elem_location entry, it assumes that the dwarf-block contains a simple DW_OP_deref, a constant and DW_OP_plus. Then it takes the constant, divides it by the pointer-size and then it has the index-element, just like it had when using stabs or with older c ++ compilers. So the actual Dwarf-block is not evaluated at all. But hey, it works now, even with FPC. > Are you actually passing through gnu-v2-abi.c? Everythong ought to be > on the v3 abi unless this is another FPC quirk... It's (as almost always) the other way around and a gcc quirk. The default is gnu-v2. But when a symbol's name start with '_Z' then it is set to gnu-v3. Really, gdb contains a pile of hacks to get it working with gcc. That's not a problem but sometimes difficult when other compilers try to work with the official Dwarf-specifications. Regards, Joost van der Sluis.