From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4604 invoked by alias); 23 Sep 2011 08:31:02 -0000 Received: (qmail 4579 invoked by uid 22791); 23 Sep 2011 08:30:58 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 23 Sep 2011 08:30:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8N8Ua31014239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 04:30:36 -0400 Received: from host1.jankratochvil.net (ovpn-116-16.ams2.redhat.com [10.36.116.16]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8N8UXtd021240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 04:30:36 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p8N8UXwF004968; Fri, 23 Sep 2011 10:30:33 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p8N8UWxr004967; Fri, 23 Sep 2011 10:30:32 +0200 Date: Fri, 23 Sep 2011 08:37:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch 11/12] entryval#2: @entry values even for references Message-ID: <20110923083032.GA5996@host1.jankratochvil.net> References: <20110913195046.GL12849@host1.jankratochvil.net> <201109211632.44816.pedro@codesourcery.com> <20110922214753.GA26184@host1.jankratochvil.net> <201109230042.03104.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109230042.03104.pedro@codesourcery.com> 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-09/txt/msg00424.txt.bz2 On Fri, 23 Sep 2011 01:42:02 +0200, Pedro Alves wrote: > Just a quick reply, can't reply in full now: > > On Thursday 22 September 2011 22:47:53, Jan Kratochvil wrote: > > (b) Even if I create such DWARF attribute by hand the expression `s@entry.b' > > for parameter `S &s' of type `class S { char a, b; };' never reaches this > > point of code because: > > That's not the case that descends into subfields of an object with > embedded_offset != 0. It's when printing the _whole struct_, and > gdb goes and prints a at embedded_offset 0 of s, and then b at > embedded_offset==offsetof(typeof(s), b) of s. > > Try "p s@entry" ? First c_val_print enters with TYPE_CODE_REF, embedded_offset==0 being lval_computed with entry_data_value_funcs. coerce_ref_if_computed succeeds, returning deref_val with TYPE_CODE_STRUCT, embedded_offset==0 being lval_memory at some inferior address. In this moment common_val_print is called with this new lval_memory value, the former original_value with lval_computed is forgotten, there is no longer anything non-standard (anything related to entry_data_value_funcs). c_val_print cannot use for TYPE_CODE_REF coerce_ref as it has to respect embedded_offset and the current sub-type etc. This is needed for the case of foo.r in `struct { long l; long &r } foo;'. But the difference with entry_data_value_funcs is that such value can never be a part of anything else, it is always a toplevel value. embedded_offset != 0 for entry_data_value_funcs would try to take the reference-pointer from some shifted (and invalid) location. embedded_offset != 0 for entry_data_value_funcs does not express the offset in the target structure (pointed_to_offset would express that). Entry values are not self-contained, they can reference other data which are no longer in the entry-time state. This is a defect of the design but fixing that would mean probably excessive and unbound debug info sizes. Thanks, Jan