From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20511 invoked by alias); 23 Sep 2011 09:50:51 -0000 Received: (qmail 20501 invoked by uid 22791); 23 Sep 2011 09:50:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Sep 2011 09:50:26 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R72On-00043b-Qh from pedro_alves@mentor.com ; Fri, 23 Sep 2011 02:50:26 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2011 10:50:24 +0100 From: Pedro Alves To: Jan Kratochvil Subject: Re: [patch 11/12] entryval#2: @entry values even for references Date: Fri, 23 Sep 2011 10:27:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <20110913195046.GL12849@host1.jankratochvil.net> <201109230042.03104.pedro@codesourcery.com> <20110923083032.GA5996@host1.jankratochvil.net> In-Reply-To: <20110923083032.GA5996@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109231050.22720.pedro@codesourcery.com> 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/msg00427.txt.bz2 On Friday 23 September 2011 09:30:32, Jan Kratochvil wrote: > 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. Sorry, in the hurry, I hadn't noticed you had used `S &s; class S { char a, b; };'. That's not the case I raised originally. The case is an entry val of type `struct { int a; long &b; }'. Calling an entry object of that type `s', if we "print s@entry", I think we'll: print A (TYPE_CODE_INT) at embedded_offset 0 of S, and then B at embedded_offset==offsetof(typeof(s), b) of S (e.g., 8). B will be TYPE_CODE_REF here, and coerce_ref_if_computed on S will wrongly operate on the contents of the whole S (because it loses embedded_offset), instead of working with the B contents of S. > 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. -- Pedro Alves