From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23335 invoked by alias); 17 Feb 2006 14:24:20 -0000 Received: (qmail 23034 invoked by uid 22791); 17 Feb 2006 14:24:19 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 14:24:18 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FA6Wo-0003VG-AN for gdb@sources.redhat.com; Fri, 17 Feb 2006 17:24:15 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FA6Wj-0003Uu-2G; Fri, 17 Feb 2006 17:24:05 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI: type prefixes for values Date: Fri, 17 Feb 2006 14:26:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <200602171658.23427.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602171724.03824.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00180.txt.bz2 On Friday 17 February 2006 17:10, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 17 Feb 2006 16:58:22 +0300 > > Cc: gdb@sources.redhat.com > > > > > > It's only avaiable in tooltip text for a variable. So far, no > > > > complaints. > > > > > > I don't see how is this contrary to what GDB assumes. GDB passes the > > > information to the front end; how the front end displays it, is > > > entirely up to the front end. > > > > Because for display in variable tree, frontend prefers not to show any > > type, and for display in varible tooltips, it prefers to show the type > > after the value, not before. > > That's quite specific to that front end, right? We cannot possibly > assume they all will behave like that. Exactly. Then why format value in a specific way that suites some frontends, but not others. > > - The parsing of that value will have to be done by ad-hoc code, which is > > contrary to MI-goal of being easily parsable. > > Why ad-hoc? if you have {}, parse it, if not, don't. Why is this > simple rule hard for a parser? Here's the relevant part from KDevelop: if (*start == '{') { // Gdb uses '{' in two cases: // - composites (arrays and structures) // - pointers to functions. In this case type is // enclosed in "{}". Not sure why it's so, as // when printing pointer, type is in parenthesis. if (type == typePointer) { // Looks like type in braces at the beginning. Strip it. start = skipDelim(start, '{', '}'); } else { // Looks like composite, strip the braces and return. return QCString(start+1, end - start -1); } You see, if I strip everything {}-enclosed at the beginning of value, I'll never show any structures. And how do I decide if the value is a pointer, or structure? That code was written before me, and is 100 lines in size. And the only way to reliably tell if a variable is a pointer or not is to issue -var-type-info, which, according to you, is not necessary if there's {} in the value. Or I might look after the closing brace and see if there's anything there, which starts to look pretty hacky. > > > Then perhaps we should add the type info to all arguments, instead of > > > removing it from where it exists now. > > > > It might be good idea, but why don't add it as a separate field? I.e. > > instead of > > > > ^done,value="(int *) 0x0" > > > > you'll get > > > > ^done,value="0x0",type="int *" > > Fine with me. So, are patches to the effect of removing type from value, and moving it to a separate field welcome? - Volodya