From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15689 invoked by alias); 13 May 2010 17:18:17 -0000 Received: (qmail 15680 invoked by uid 22791); 13 May 2010 17:18:16 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 May 2010 17:18:08 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4DHHxvP012816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 13:18:00 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4DHHwTD020325; Thu, 13 May 2010 13:17:58 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o4DHHsZq004307; Thu, 13 May 2010 13:17:57 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 5CA0837881C; Thu, 13 May 2010 11:17:54 -0600 (MDT) From: Tom Tromey To: "Pierre Muller" Cc: , "'FPC Core Developer List'" Subject: Re: [RFC] dwarf debug information: Handle Free Pascal virtual table indexes References: <23651.5388860882$1273672053@news.gmane.org> <11064.3996195451$1273708856@news.gmane.org> Reply-To: tromey@redhat.com Date: Thu, 13 May 2010 17:29:00 -0000 In-Reply-To: <11064.3996195451$1273708856@news.gmane.org> (Pierre Muller's message of "Thu, 13 May 2010 02:00:45 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00279.txt.bz2 >>>>> "Pierre" == Pierre Muller writes: Pierre> you have to take into account that Pierre> I know about nothing about DWARF :( No problem, don't worry about it :-) Pierre> DW_AT_vtable_elem_location attribute a BLOCK consisting of Pierre> a DW_OP_constu marker followed by a unsigned_leb128 value Pierre> to indicate the offset within the virtual table of a virtual Pierre> function. Tom> By my reading, this is incorrect DWARF. Or is there more to the Tom> expression than that? Pierre> What do you exactly mean by expression here? The value of DW_AT_vtable_elem_location is a DWARF location expression. >From the DWARF 4 (review) spec: An entry for a virtual function also has a DW_AT_vtable_elem_location attribute whose value contains a location description yielding the address of the slot for the function within the virtual function table for the enclosing class. The address of an object of the enclosing type is pushed onto the expression stack before the location description is evaluated. One thing that would be helpful is if you ran "readelf -w" (or some other DWARF dumper) on a program created by FPC that has this attribute, then posted the DIE in question. Also ... I forgot to mention this yesterday but I am curious to know how gdb gets into an error state here. My reading of the code in this area is that gdb might issue a complaint, but it won't error out. I would expect it to ignore the attribute it can't recognize and continue on. Pierre> I could indeed replace the call read_unsigned_leb128 Pierre> by a call to decode_locdesc using DW_BLK(attr) but this Pierre> is still different from the other call to decode_locdesc Pierre> earlier in the same function, because context is not set in Free Pascal Pierre> case. Is there some deep reason for this? (I don't know.) Offhand it looks reasonably safe to just set it. I realize you may still need a pascal-specific case, since gdb doesn't handle the full generality of DWARF in this area. But if so, I think this should be explicit. Tom