From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8378 invoked by alias); 2 Jun 2010 18:54:09 -0000 Received: (qmail 8359 invoked by uid 22791); 2 Jun 2010 18:54:08 -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; Wed, 02 Jun 2010 18:53:59 +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 o52IrwNh029614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jun 2010 14:53:58 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o52Irt0B001418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jun 2010 14:53:57 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o52IrtYY017374; Wed, 2 Jun 2010 20:53:55 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o52Irsbm017373; Wed, 2 Jun 2010 20:53:54 +0200 Date: Wed, 02 Jun 2010 18:54:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: partially fix empty DW_OP_piece Message-ID: <20100602185354.GA11125@host0.dyn.jankratochvil.net> References: <20100514223521.GA3975@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) 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: 2010-06/txt/msg00047.txt.bz2 On Tue, 01 Jun 2010 18:41:51 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > Tom> The other way is to simply remove val_print entirely and make all of > Tom> printing work using values. I think this is the route I would prefer. > > Jan> That could hopefully solve the problem of missing type-associated object > Jan> address for DW_OP_push_object_address for the VLA (variable length arrays) > Jan> patch. > > I am curious to know what you need here. I do not understand the prototype: int val_print (struct type *type, const gdb_byte *valaddr, int embedded_offset, CORE_ADDR address, struct ui_file *stream, int recurse, const struct value_print_options *options, const struct language_defn *language) struct language_defn: int (*la_val_print) (struct type *type, const gdb_byte *contents, int embedded_offset, CORE_ADDR address, struct ui_file *stream, int recurse, const struct value_print_options *options); There cannot be any `const gdb_byte *contents' for types with DWARF_block* as their attribute (=TYPE_DYNAMIC from archer-jankratochvil-vla) as DWARF expression evaluation arbitrarily accesses inferior memory during DWARF_block* evaluation for DW_AT_upper_bound and others. VLA patchset also deals with two ADDRESSes - object address (needed for DWARF_block*'s DW_OP_push_object_address evaluation) and data address (DW_AT_data_location, neede for the content printing - but data address can be derived from the object address; apparently data address cannot be converted to object address). OTOH there cannot be any `CORE_ADDR address' where the content could be read from - for example for internal variables. Therefore we need to use both accesses depending on the object class. I believe `struct value' stricly being LAZY can be used for inferior objects (and non-LAZY `struct value' for internal variables). Only in some final moment (of arrays dereferencing etc.) the inferior LAZY vary can be fetched. > I started by looking briefly at replacing val_print. Here you probably mean la_val_print->la_value_print unification: struct language_defn: int (*la_val_print) (struct type *type, const gdb_byte *contents, int embedded_offset, CORE_ADDR address, struct ui_file *stream, int recurse, const struct value_print_options *options); by keeping only existing: struct language_defn: int (*la_value_print) (struct value *, struct ui_file *, const struct value_print_options *); > This looks pretty big, though. So I looked into other solutions. I believe it will need to be done anyway for the sane integration of the VLA patchset. > So, currently I am thinking I will go through my existing patch and have > it pass a value instead of lval_funcs. Of course this means a lot of > redundant info, which is ugly. Do you mean the unification proposed above or some other extension? > There are barriers to removing val_print. I think the biggest one, > conceptually, is that recursion in val_print means making new values, Yes, I think it is required for the case of Pascal arrays of strings - each element of Pascal array is a VLA array (=string); gdb.pascal/arrays.exp by Joost van der Sluis in archer-jankratochvil-vla. Each element is a full-blown dynamic objects without much possibilities of a simplication. > which means copying the value contents. This can be expensive. (Of > course there are solutions to that, reference counting the value > contents comes to mind.) Couldn't be just the `struct value' kept LAZY and creating struct values for the dereferenced elements only with properly adjusted object address? Thanks, Jan