From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27689 invoked by alias); 29 Jul 2011 15:30:36 -0000 Received: (qmail 27678 invoked by uid 22791); 29 Jul 2011 15:30:36 -0000 X-SWARE-Spam-Status: No, hits=-7.0 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; Fri, 29 Jul 2011 15:30:22 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6TFUM3Z022699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 29 Jul 2011 11:30:22 -0400 Received: from host1.jankratochvil.net (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6TFUIjW028214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 11:30:21 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p6TFUHAx014674; Fri, 29 Jul 2011 17:30:17 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p6TFUHTe014671; Fri, 29 Jul 2011 17:30:17 +0200 Date: Fri, 29 Jul 2011 15:35:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [patch 02/12] entryval: Basic parameter values recovery Message-ID: <20110729153017.GD14528@host1.jankratochvil.net> References: <20110718201528.GC30496@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00805.txt.bz2 On Tue, 19 Jul 2011 16:19:00 +0200, Tom Tromey wrote: > >>>>> "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. done. > 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. done. There are now some tests for `double' recomputations, after Jakub's fix of GCC PR debug/49846. > 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. I agree, the DWARF data are no longer copied. > 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. enum field_loc_kind is used only for types comparisons in gdb/python/ . Implemented there FIELD_LOC_KIND_DWARF_BLOCK. TYPE_CALLING_CONVENTION is not used at all in gdb/python/ so I haven't tried to implement in gdb/python/ also TYPE_TAIL_CALL_LIST where both belong to type_specific.func_stuff now. I do not see how user can "fetch" the type kind in gdb/python/ , convert_field does not access FIELD_LOC_KIND nor TYPE_FIELD_LOC_KIND in any way. It will be in a new patchset resubmit. Thanks, Jan