From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22223 invoked by alias); 2 Jun 2010 20:07:57 -0000 Received: (qmail 22000 invoked by uid 22791); 2 Jun 2010 20:07:54 -0000 X-SWARE-Spam-Status: No, hits=-5.8 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 20:07:45 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o52K7hKQ013417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jun 2010 16:07:43 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o52K7h4P025900; Wed, 2 Jun 2010 16:07:43 -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 o52K7gvm001650; Wed, 2 Jun 2010 16:07:42 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id AA3CE3782DC; Wed, 2 Jun 2010 14:07:41 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFC: partially fix empty DW_OP_piece References: <20100514223521.GA3975@host0.dyn.jankratochvil.net> <20100602185354.GA11125@host0.dyn.jankratochvil.net> Reply-To: Tom Tromey Date: Wed, 02 Jun 2010 20:07:00 -0000 In-Reply-To: <20100602185354.GA11125@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Wed, 2 Jun 2010 20:53:54 +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-06/txt/msg00054.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> int (*la_val_print) (struct type *type, Jan> const gdb_byte *contents, Jan> int embedded_offset, CORE_ADDR address, Jan> struct ui_file *stream, int recurse, Jan> const struct value_print_options *options); Jan> There cannot be any `const gdb_byte *contents' for types with Jan> DWARF_block* as their attribute (=TYPE_DYNAMIC from Jan> archer-jankratochvil-vla) as DWARF expression evaluation Jan> arbitrarily accesses inferior memory during DWARF_block* evaluation Jan> for DW_AT_upper_bound and others. I think the current gdb model is that a value is a snapshot of some inferior state at a particular moment. So, for VLA I would say that the bounds ought to be fixed at the time the snapshot is taken. I suppose this would mean introducing some copy of the type. Jan> OTOH there cannot be any `CORE_ADDR address' where the content Jan> could be read from - for example for internal variables. Yeah. val_print doesn't usually read memory, though. The address is only occasionally used. Tom> I started by looking briefly at replacing val_print. Jan> Here you probably mean la_val_print->la_value_print unification: Yes. Tom> So, currently I am thinking I will go through my existing patch and have Tom> it pass a value instead of lval_funcs. Of course this means a lot of Tom> redundant info, which is ugly. Jan> Do you mean the unification proposed above or some other extension? Right now what I've done is change val_print to: 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 *val, const struct value_print_options *options, const struct language_defn *language) That is, I added the new 'val' argument. This is only used for bit validity testing. Jan> Couldn't be just the `struct value' kept LAZY and creating struct Jan> values for the dereferenced elements only with properly adjusted Jan> object address? One problem is that not all values are lazy. Also, record_latest_value specifically makes a value not lazy, but this could be fixed somehow. Maybe this problem is not very important though. Tom