From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18259 invoked by alias); 24 May 2016 14:51:44 -0000 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 Received: (qmail 17866 invoked by uid 89); 24 May 2016 14:51:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=thousand, pictures X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 May 2016 14:51:42 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 42D254AD6F; Tue, 24 May 2016 14:51:41 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4OEpewU030645; Tue, 24 May 2016 10:51:40 -0400 Subject: Re: [PATCH v2][PR gdb/19893] Fix handling of synthetic C++ references To: Martin Galvan References: <1464019228-11131-1-git-send-email-martin.galvan@tallertechnologies.com> <04d07644-c6ed-88ae-f1de-cba46e875f2d@redhat.com> Cc: gdb-patches From: Pedro Alves Message-ID: Date: Tue, 24 May 2016 14:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00423.txt.bz2 On 05/24/2016 03:07 PM, Martin Galvan wrote: > Thanks for the answer! > > On Tue, May 24, 2016 at 7:46 AM, Pedro Alves wrote: >> ... I still don't know what to think of this -- I simply don't understand it whether >> you're doing this because it makes sense, or because doing otherwise would be hard >> to do? > > From a consistency point of view, it's probably not the right thing. > All of the synthetic pointer cases I've tested always show " pointer>" instead of "@address". But normal pointers don't print @address either, only references do. Not printing "@address" with "set print object off" seems like hiding information from the user, information that we could show. We always print it for non-synthetic references, AFAICS. > Or at least I don't know > how to do it off the top of my head. I'd have to make value_addr not > return a not_lval when passing it a synthetic ref, which I'm not sure > it's right either. Your comment in the patch, in generic_val_print_ref, reads: + if options->objectprint is true, c_value_print will call value_addr + on the reference, which coerces synthetic references and returns a + 'not_lval'. */ So if that works, I don't understand -- wouldn't calling value_addr or coerce_ref in generic_val_print_ref if you have a synthetic reference, or any reference even, be what you'd want? > > I *could*, however, manually call > value->location.computed.funcs->check_synthetic_pointer in > generic_val_print_ref instead of using value_bits_synthetic_pointer, > thus avoiding the check for lval_computed. But that's a bit ugly IMHO. I don't understand this one. Only lval_computed values have a "location.computed.funcs" to call. > >> - Can you show an example output? (set print object on/off, etc. whatever might be >> handy to clearly explain that that is about). >> Pictures are really worth a thousand words. :-) So is the problem that this bit: if (options->addressprint) { CORE_ADDR addr = extract_typed_address (valaddr + embedded_offset, type); doesn't work / doesn't make sense with synthetic pointers? Should we be calling value_addr instead? Or are we perhaps missing a lval_funcs method? (Ideally, all value properties/methods would go through a vtable like lval_funcs; think "making struct value a proper C++ class" going forward.) > Here, 0x601038 is the address of the structure 'ref' is referencing. > This is consistent with the output for non-synthetic references, where > the referenced value's address is shown. > >> - Is this covered by any testcase? I looked for "object" in the whole patch and >> didn't seem to find it. > > Not that I know of. Should I add a test for this to implref-struct? I don't know where, but I think this should indeed be covered by tests somewhere. Thanks, Pedro Alves