From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31420 invoked by alias); 7 Oct 2010 18:13:46 -0000 Received: (qmail 31408 invoked by uid 22791); 7 Oct 2010 18:13:43 -0000 X-SWARE-Spam-Status: No, hits=-6.2 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; Thu, 07 Oct 2010 18:13:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o97IDE60018706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 14:13:14 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o97IDCqW002408; Thu, 7 Oct 2010 14:13:12 -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 o97IDAaK004285; Thu, 7 Oct 2010 14:13:11 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8F2AC37897F; Thu, 7 Oct 2010 12:13:10 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [RFA] valprint.c / *-valprint.c: Don't lose `embedded_offset' References: <201010070207.02695.pedro@codesourcery.com> Date: Thu, 07 Oct 2010 18:13:00 -0000 In-Reply-To: <201010070207.02695.pedro@codesourcery.com> (Pedro Alves's message of "Thu, 7 Oct 2010 02:07:02 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (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-10/txt/msg00126.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> A bit of explaining on why this is necessary. In the context of Pedro> tracepoints, I'm adding support for partial/incomplete objects. Pedro> That is, say, when printing an array where only a few elements Pedro> have been collected, print what you can, and print something like Pedro> "" (like ) for what has not been Pedro> collected. Looks nice. Pedro> Trouble is in languages other than C/C++ where the Pedro> advance-embedded_offset-don't-touch-valaddr-or-address contract Pedro> isn't compromised in many places. I think the embedded_offset is very confusing. Every time I have to fix a bug in it, I have to re-learn what it really means. Perhaps next time I will plan ahead and fix the commentary in value.c to be more clear (to me at least). Pedro> I have no way of testing the D or SCM changes, though the former's Pedro> are quite small, and the latter's, I'm not sure who cares at all. My belief is that gdb's guile support has bit-rotted -- specifically, that guile has changed incompatibly. I will ask. Perhaps we can remove it. Pedro> All in all, I think it's just better to be consistent throughout. Pedro> I know I got mighty confused with some functions taking adjusted Pedro> `valaddr' and `address', while others taking `embedded_offset' Pedro> into account. Maybe some day we will not allow passing around Pedro> a NULL `val', and thus we will be able to get rid of `valaddr' Pedro> and `address' parameters throughout, and instead get those from Pedro> the value directly. I don't plan to actually do that, but Pedro> this seems like a step in that direction. I was going to do this last time I had to add a parameter to the whole val_print hierarchy, but then blinked. I think we should just get rid of val_print entirely, and only have value_print, passing around values. If that is not efficient enough (too much copying or something), we can change struct value to make it efficient. What do you think of that? This isn't a high priority for me, either, but I suspect we'll need another round of changes here to support DW_OP_GNU_implicit_pointer. I did not read the patch extremely closely. What I did read looks reasonable. Unfortunately the nature of a patch like this is that it is very hard to know whether some spot was missed :-( Tom