From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18658 invoked by alias); 22 Sep 2011 21:48:23 -0000 Received: (qmail 18644 invoked by uid 22791); 22 Sep 2011 21:48:20 -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; Thu, 22 Sep 2011 21:48:01 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8MLlvJw007093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 17:47:57 -0400 Received: from host1.jankratochvil.net (ovpn-116-24.ams2.redhat.com [10.36.116.24]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8MLltBl024471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 17:47:56 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p8MLlspC016739; Thu, 22 Sep 2011 23:47:54 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p8MLlr9S016737; Thu, 22 Sep 2011 23:47:53 +0200 Date: Thu, 22 Sep 2011 22:49: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: <20110922214753.GA26184@host1.jankratochvil.net> References: <20110913195046.GL12849@host1.jankratochvil.net> <201109161326.09350.pedro@codesourcery.com> <20110916182434.GA12066@host1.jankratochvil.net> <201109211632.44816.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109211632.44816.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/msg00417.txt.bz2 On Wed, 21 Sep 2011 17:32:44 +0200, Pedro Alves wrote: > But not in the example I gave? Or are you saying that there can't be > an entryval whose type is a struct? Theoretically there can be, just: (a) GCC currently cannot produce DW_AT_GNU_call_site_data_value (for the struct content) in such case (it produces only DW_AT_GNU_call_site_value - for the struct referencing pointer). (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: #0 coerce_ref_if_computed (arg=0x202c8c0) at value.c:3096 #1 in coerce_ref (arg=0x202c8c0) at value.c:3115 #2 in coerce_array (arg=0x202c8c0) at value.c:3132 #3 in value_struct_elt (argp=0x7fffffffd258, args=0x0, name=0x26fccd0 "b", static_memfuncp=0x0, err=0xea593f "structure") at valops.c:2306 #4 in evaluate_subexp_standard (expect_type=0x0, exp=0x26fcc90, pos=0x7fffffffd68c, noside=EVAL_NORMAL) at eval.c:1966 #5 in evaluate_subexp_c (expect_type=0x0, exp=0x26fcc90, pos=0x7fffffffd68c, noside=EVAL_NORMAL) at c-lang.c:720 #6 in evaluate_subexp (expect_type=0x0, exp=0x26fcc90, pos=0x7fffffffd68c, noside=EVAL_NORMAL) at eval.c:76 #7 in evaluate_expression (exp=0x26fcc90) at eval.c:151 #8 in print_command_1 (exp=0x7fffffffde6f "s@entry.b", inspect=0, voidprint=1) at ./printcmd.c:973 So in all the cases like this one c_val_print already gets original_value which is no longer "magic" in any way, it is already coerce-ref-ed. (c) Your: On Fri, 16 Sep 2011 14:26:09 +0200, Pedro Alves wrote: > E.g., `struct { long l; long &r } foo;', and we're `p foo', which descends > into printing R at FOO + offset of R ? also cannot lead much to anything as if the parameter is of struct s { long l; long &r; }; void f (struct s p) {} then `print p@entry' just does not get `entry_data_value_funcs' at all because `p' is not TYPE_CODE_REF. And anyway after any operation with `p' it gets coerce-ref-ed, it is no longer "magic" and that new code is nop. > If that's the case, I'm okay with the assert for now. I think so. > > If it should work really correctly there are more cases to catch such as > > f77_print_array (*) being passed original_value etc. The correct way would be > > the rework to full struct value * printing > > http://sourceware.org/ml/gdb-patches/2010-10/msg00127.html > > but I did not want to get deeper in the patchset dependencies. > > I'm not sure that'd be necessary. As I do not see possible how to exploit the current gdb_assert()s I do not see which parts to fix. > (the first 2 steps are complete, btw). I see, great, (2) thanks to val_print_scalar_formatted. > That would change the running-offset scheme, > allowing value contents to be even more lazy, but that does not > mean the current scheme doesn't work. >From the larger picture the current API does not work as `struct value' should reference all the memory it needs, not just the single contiguous block value->contents. It breaks archer-jankratochvil-vla where single value uses discontiguous memory areas. With FSF GDB one can see it on untracked virtual method table: class C { virtual void m(); } c; void C::m() {} (gdb) file 8.o Reading symbols from 8.o...done. (gdb) set $a=c (gdb) p $a.m $1 = {void (C * const)} 0 (gdb) file No executable file now. Discard symbol table from `8.o'? (y or n) y No symbol file now. (gdb) p $a.m There is no member named m. > E.g, if entryval's lval_funcs->coerce_ref took an embedded_offset, The problem is that if embedded_offset != 0 for entry_data_value_funcs value it means one cannot derefence it. It is like a request to coerce_ref `struct { long &r; } foo;' with embedded offset != 0. It is error, its dereference exceeds its ->contents length. entry_data_value_funcs value is created with embedded_offset == 0 and any futher operation has to coerce_ref it first. > and returned the target value with value_offset adjusted The target value is at a new/different memory location, I do not see why embedded_offset should map to value_offset there. The existing value_at+unpack_pointer code also does not set value_offset. You are rather suggesting handling pointed_to_offset != 0 remapping during the coerce_ref but that seems very out of topic here, it is also always 0 for entry_data_value_funcs. > you'd be almost there? Thanks for thinking more about it but I see entry_data_value_funcs as a special kind of value. Sure it is not perfect as for example entry-value `int *' will dereference to actual-value (not entry-value) `int'. > The problem is that you share/refcount the target > value, so we'd either need to unshare it so we could have copies with > different offsets set, or we'd add a new lval_computed type that serves > as view with offset into a current value, as I proposed in that URL, > but without changing everything else in valprint. I do not think this comment is relevant presuming offset really should be == 0. Thanks for the review, Jan