From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29302 invoked by alias); 19 Jan 2009 15:22:27 -0000 Received: (qmail 29293 invoked by uid 22791); 19 Jan 2009 15:22:27 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Jan 2009 15:22:19 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id n0JFLBPN677890 for ; Mon, 19 Jan 2009 15:21:11 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0JFLBmK3158144 for ; Mon, 19 Jan 2009 16:21:11 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0JFLAsv004282 for ; Mon, 19 Jan 2009 16:21:11 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n0JFLAtI004277; Mon, 19 Jan 2009 16:21:10 +0100 Message-Id: <200901191521.n0JFLAtI004277@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 19 Jan 2009 16:21:10 +0100 Subject: Re: [patch] [VLA 2/2] Interpret FIELD_LOC_KIND_DWARF_BLOCK fields To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Mon, 19 Jan 2009 15:22:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker), jimb@red-bean.com (Jim Blandy), burnus@net-b.de (Tobias Burnus) In-Reply-To: <20090113014122.GA27831@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Jan 13, 2009 02:41:22 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2009-01/txt/msg00422.txt.bz2 Jan Kratochvil wrote: > check_typedef() will contain a memory leak with this patch. This has been > fixed by Tom Tromey's + mine garbage collector to be posted later from: > http://sourceware.org/gdb/wiki/ArcherBranchManagement > archer-jankratochvil-type-refcount If this is a pre-req, I think we should get that in the tree first ... > +/* Evaluate DWARF expression at DATA ... DATA + SIZE with its result readable > + by dwarf_expr_fetch (RETVAL, 0). FRAME parameter can be left NULL to call > + get_selected_frame to get its value. Freeing of returned dwarf_expr_context > + is remembered on the current cleanup chain. */ > + > +static struct dwarf_expr_context * > +dwarf_expr_prep_ctx (struct frame_info *frame, gdb_byte *data, > + unsigned short size, struct dwarf2_per_cu_data *per_cu) > +{ > + struct dwarf_expr_context *ctx; > + struct dwarf_expr_baton baton; > + > + if (!frame) > + frame = get_selected_frame (NULL); I don't particularly like this. We've been trying to get away from having low-level routines depend on "global" setting like the currently selected frame ... Why is it correct to always evaluate VLA sizes relative to the currently selected frame? We might need to use some other frame, e.g. when re- evaluating watchpoint expressions due to a shared-library event ... It appears the need for using global data stems from the design decision to have VLA sizes implicitly evaluated during the check_typedef call. I'm wondering whether it wouldn't be better to use some other interface to get at the current length of a VLA type, explicitly relative to a specified frame (and possibly a specified data object). B.t.w. this might also address the memory-management problem by not having to allocate new types in the first place. > --- gdb-cvs-dwarf2_get_attr_constant_value/gdb/dwarf2loc.h 2009-01-11 17:09:14.000000000 +0100 > +++ gdb-cvs-dwarf_block-eval/gdb/dwarf2loc.h 2009-01-12 10:37:22.000000000 +0100 > @@ -72,4 +72,7 @@ struct dwarf2_loclist_baton > extern const struct symbol_ops dwarf2_locexpr_funcs; > extern const struct symbol_ops dwarf2_loclist_funcs; > > +extern CORE_ADDR dwarf_locexpr_baton_eval > + (struct dwarf2_locexpr_baton *dlbaton); Making this dwarf2-specific function directly callable seems to break the abstraction layer that "hides" specific details of any particular debug info formati from common code. However, I'm not sure I see a clean solution for this. Ideally, we'd have something like a LOC_COMPUTED with callback functions, to handle format-specific field_loc_kind values. But that would require adding a new pointer to "struct field", which I don't really like either as this is a quite space-critical data structure ... I guess we can live for now with the broken abstraction, unless someone has some better idea. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com