From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12148 invoked by alias); 17 May 2012 12:58:11 -0000 Received: (qmail 12139 invoked by uid 22791); 17 May 2012 12:58:10 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL 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; Thu, 17 May 2012 12:57:52 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SV0H8-00053q-0X from Vladimir_Prus@mentor.com ; Thu, 17 May 2012 05:57:50 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 05:57:33 -0700 Received: from [172.30.0.172] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 17 May 2012 13:57:48 +0100 Message-ID: <4FB4F5C8.3060701@codesourcery.com> Date: Thu, 17 May 2012 12:58:00 -0000 From: Vladimir Prus User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= CC: Tom Tromey , xgsa , "gdb-patches@sourceware.org" , Subject: Re: [patch] Use the string returned by pretty printer for MI varobjs instead of "{...}" References: <305151335125397@web28e.yandex.ru> <87likttnme.fsf@fleche.redhat.com> <20120516010500.GB3321@klara.mpi.htwm.de> <87zk98qijh.fsf@fleche.redhat.com> <20120517121923.GB6350@klara.mpi.htwm.de> In-Reply-To: <20120517121923.GB6350@klara.mpi.htwm.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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/msg00651.txt.bz2 On 17/05/12 16:19, André Pönitz wrote: > On Wed, May 16, 2012 at 08:58:42AM -0600, Tom Tromey wrote: >>>>>>> writes: >> >> Tom> My recollection is that the code originally worked this way, but >> Tom> Vladimir asked for the "{...}" behavior specifically. >> >> André> It might affect frontends taking a "{...}" as indication that >> André> there are childrens. In fact, I just found some code using that >> André> as a shortcut. >> >> That code is just plain broken, though. The has_more field conveys >> this information. > > If you say so. > > 'git blame' thinks you added it in September 2009, so gdb 7.0 is > probably the first one that has it. Calling code "broken" just > because it handles (also...) "legacy" setups is a bit of a stretch > in my opinion. > > In any case, I was merely trying to convey the idea that an > unsuspecting frontend implementor might read the documentation > in a way that would be incompatible with the change. > > I am personally not affected by any change in the -var-* > output, so maybe I should not have bothered to comment at all. > > If you really want to read more into the comment than what was > actually written, then perhaps a friendly nudge to adapt the > documentation to existing practice. I has been quite a while, but I think I was primarily concerned that GDB would abuse value string on varobj to show what GDB thinks is the right rendering of data. E.g. while "[5]" as top-level value might be a reasonable rendition for an array with 5 children, it's not entirely clear why GDB's machine interface should take liberties at telling frontend how to render that. Neither "[", nor 5, nor "]" is integral part of data, and as soon as GDB outputs that, frontend has no way of knowing whether this is GDB trying to be helpful, or really interesting data that cannot be obtained in any other way. -- Vladimir Prus CodeSourcery / Mentor Graphics http://www.mentor.com/embedded-software/