From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16196 invoked by alias); 17 Feb 2006 10:29:50 -0000 Received: (qmail 16183 invoked by uid 22791); 17 Feb 2006 10:29:49 -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 10:29:48 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FA2rw-0004TT-OC for gdb@sources.redhat.com; Fri, 17 Feb 2006 13:29:45 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FA2ro-0004T9-Kl; Fri, 17 Feb 2006 13:29:36 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI: type prefixes for values Date: Fri, 17 Feb 2006 10:29:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602171329.34297.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/msg00165.txt.bz2 On Friday 17 February 2006 13:22, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 17 Feb 2006 12:08:32 +0300 > > > > some time ago I've raised the question why MI output sometimes prefixes > > variable values with it's type. For example: > > > > -data-evaluate-expression *p3 > > ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" > > (gdb) > > > > (note the {int (int)} part). The part does not make sense for a GUI and > > must be removed by a specially written code. > > > > See: > > > > http://article.gmane.org/gmane.comp.gdb.devel/13477 > > And you were answered in that thread that this prefix is to show you > the signature of a function to which p3 is a pointer. That is, GDB is > telling you that p3 points to a function which accepts a single int > argument and returns an int. > > > In the end, I've inquired why such prefixes cannot be dropped: > > > > http://article.gmane.org/gmane.comp.gdb.devel/13539 > > Are you saying that you don't want to show your users the fact that > the pointed object is a function? At the very least, not in the way that gdb assumes. The type prefix is removed the from variable value shown to the user. > > I imagine it's a simple matter of wrapping some code in > > "ui_output_is_mi_like_p". Can somebody comment on this proposal? > > I think this will lose useful information. So for now I object. You can get the type information via the -var-info-type, which is more formal way to get this information. A frontend is in position to call -var-info-type as needed and make UI presentation decision based on that as it likes. With mandatory "{}" prefix frontend should make special efforts to remove that part, which is not formally documented. > > Also, I note that gdb is currently inconsitent even within itself: > > > > (gdb) > > -thread-select 2 > > ^done,new-thread-id="2",frame={level="0",func="thread", > > args=[{name="p",value="0x0"}],.......... > > (gdb) > > -stack-list-arguments 1 0 0 > > ^done,stack-args=[frame={level="0", > > args=[{name="p",value="(void *) 0x0"}]}] > > > > Note that first output has "0x0" as value of 'p', and the second has > > "(void *)0x0". > > Also, the first one shows the func= part, the second doesn't. Heh, the second is not supposed to show func= part at all. MI does not have a command equivalent to "backtrace". One has to list -stack-list-frames (that does include func=) and -stack-list-arguments (that includes only argument). BTW, not very convenient. > Looks > like a bug to me: those two should both use the same code. Should I file a bug? - Volodya