From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13159 invoked by alias); 16 May 2012 01:05:37 -0000 Received: (qmail 13148 invoked by uid 22791); 16 May 2012 01:05:35 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,KHOP_THREADED,TW_XG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cora.hrz.tu-chemnitz.de (HELO cora.hrz.tu-chemnitz.de) (134.109.228.40) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 01:05:04 +0000 Received: from 91-65-62-67-dynip.superkabel.de ([91.65.62.67] helo=localhost) by cora.hrz.tu-chemnitz.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SUSfm-0001ym-Kn; Wed, 16 May 2012 03:05:02 +0200 Date: Wed, 16 May 2012 01:05:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Tom Tromey Cc: xgsa , "gdb-patches@sourceware.org" , Vladimir_Prus@mentor.com Subject: Re: [patch] Use the string returned by pretty printer for MI varobjs instead of "{...}" Message-ID: <20120516010500.GB3321@klara.mpi.htwm.de> References: <305151335125397@web28e.yandex.ru> <87likttnme.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87likttnme.fsf@fleche.redhat.com> X-Scan-AV: cora.hrz.tu-chemnitz.de;2012-05-16 03:05:02;fd5b721e9b0e6decc93e578f37ff02ea X-Scan-SA: cora.hrz.tu-chemnitz.de;2012-05-16 03:05:02;d2676542041d7575ba1240ada7705111 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse 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: 2012-05/txt/msg00590.txt.bz2 On Tue, May 15, 2012 at 10:28:25AM -0600, Tom Tromey wrote: > >>>>> "Anton" == xgsa writes: > > Anton> The documentation for -var-create says that "for a varobj whose type > Anton> is some sort of aggregate (e.g., a struct), or for a dynamic varobj, > Anton> the 'value' attribute will not be interesting". That's not true, as > Anton> dynamic varobj could also have no children (so its value will be not > Anton> "{...}" and will be interesting). However I think the string value of > Anton> varobj that has pretty printer installed should always be returned via > Anton> MI. It could contain such a useful information as container length or > Anton> reference count for smart pointers. Moreover, it seems that this > Anton> information cannot be accessed via MI in another way. This patch > Anton> contains the proposed fix, documentation and test suite update. > > The patch itself looks fine, but I am not sure whether it should go in. > > My recollection is that the code originally worked this way, but > Vladimir asked for the "{...}" behavior specifically. It might affect frontends taking a "{...}" as indication that there are childrens. In fact, I just found some code using that as a shortcut. The safe way would be to add a new field 'formatted-value' or similar with the new value, and perhaps even announce the feature using -list-features, but I doubt this is worth the trouble. I am not sure how frontend developers interpret "27.4 gdb/mi Development and Front Ends", or how much they rely on it in general. The list of "to be expexted changes" mentions * New MI commands may be added. * New fields may be added to the output of any MI command. * The range of values for fields with specified values, e.g., in_scope (see -var-update) may be extended. It's not directly obviously to me that this list is meant to be exhaustive, and even if, whether the third bullet point covers changing existing values, but there is precedence that changing values was prefered over adding a new field in the past, so there is no real reason to not do it again. Andre'