From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19676 invoked by alias); 19 Jul 2011 14:19:20 -0000 Received: (qmail 19666 invoked by uid 22791); 19 Jul 2011 14:19:19 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ 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; Tue, 19 Jul 2011 14:19:02 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6JEJ1sA009278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Jul 2011 10:19:01 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6JEJ1ja003739; Tue, 19 Jul 2011 10:19:01 -0400 Received: from barimba (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 p6JEJ0b6004051; Tue, 19 Jul 2011 10:19:00 -0400 From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch 02/12] entryval: Basic parameter values recovery References: <20110718201528.GC30496@host1.jankratochvil.net> Date: Tue, 19 Jul 2011 14:43:00 -0000 In-Reply-To: <20110718201528.GC30496@host1.jankratochvil.net> (Jan Kratochvil's message of "Mon, 18 Jul 2011 22:15:28 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2011-07/txt/msg00466.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> +extern struct cleanup *make_cleanup_htab_delete (htab_t htab); Just a minor additional cleanup -- dwarf2read.c:cleanup_htab can now be removed. I can do this after the patch goes in if you like. Jan> + error (_("DWARF-2 expression error: DW_OP_GNU_entry_value is " Jan> + "supported only for single DW_OP_reg* " Jan> + "or for DW_OP_breg*(0)+DW_OP_deref*")); I'm a little surprised that DW_OP_GNU_regval_type isn't included here; but I suppose that if Jakub adds it to the spec and to GCC, then we can easily update. Jan> +/* Allocate a copy of BLK on CU's objfile_obstack (not comp_unit_obstack), Jan> + including a copy of the BLK DWARF code. */ Jan> + Jan> +static struct dwarf2_locexpr_baton * Jan> +dlbaton_obstack_copy (const struct dwarf_block *blk, struct dwarf2_cu *cu) I don't understand the need for this. Once we have mapped in a DWARF section, we do not unmap it until the objfile is destroyed or reloaded. At that point, the types are all destroyed as well. So, the lifetimes are already in sync, and you can just store a pointer directly to the DWARF data. We already rely on this in many cases. Jan> @@ -12624,6 +12844,8 @@ dwarf_tag_name (unsigned tag) Jan> return "DW_TAG_PGI_kanji_type"; Jan> case DW_TAG_PGI_interface_block: Jan> return "DW_TAG_PGI_interface_block"; Jan> + case DW_TAG_GNU_call_site: Jan> + return "DW_TAG_GNU_call_site"; Thanks. I wish this were more automatic; and done in one spot so we don't constantly have to update both binutils and gdb for this kind of change. Jan> + FIELD_LOC_KIND_DWARF_BLOCK /* dwarf_block */ Since the new data is stored as a field, it will change the Python API. I think there are two options: 1. Document what the fields of a function mean. 2. Disallow fetching these fields in typy_fields. I tend to prefer #2, but I can see arguments either way. Tom