From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19040 invoked by alias); 17 Feb 2006 20:41:12 -0000 Received: (qmail 19031 invoked by uid 22791); 17 Feb 2006 20:41:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 20:41:05 +0000 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k1HKeIIp001693; Fri, 17 Feb 2006 12:40:18 -0800 (PST) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id 2D9BF324016; Fri, 17 Feb 2006 12:40:18 -0800 (PST) In-Reply-To: <20060217203120.GE30881@nevyn.them.org> References: <200602171724.03824.ghost@cs.msu.su> <20060217190418.GA27304@nevyn.them.org> <20060217193556.GA28754@nevyn.them.org> <20060217195909.GA19387@brasko.net> <20060217201537.GA30881@nevyn.them.org> <20060217203120.GE30881@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D09ADF2-5A80-4B42-B4DE-2A2861C3A2AA@apple.com> Cc: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Fri, 17 Feb 2006 21:14:00 -0000 To: Daniel Jacobowitz X-IsSubscribed: yes 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/msg00223.txt.bz2 And... since the varobj's only parse the expression once when the varobj is created, getting the current values of varobj's is much faster than doing -data-evaluate-expression. Not a big deal if you are just printing one value. But if you are trying to update all the local variables on every step, this can be significant. People tend to be pretty sensitive to the speed of the "step" operation... If you're writing a front end using the MI, you are better off using variable objects for anything that you are likely to refresh more than one or two times. In Xcode, we do use -data-evaluate-expression, but only when we are doing function calls where we know the call we are making and what to expect back. In this case the overhead of the variable object is not worth the trouble. Other than that, we use varobj's... Jim On Feb 17, 2006, at 12:31 PM, Daniel Jacobowitz wrote: > On Fri, Feb 17, 2006 at 10:22:32PM +0200, Eli Zaretskii wrote: >>> Date: Fri, 17 Feb 2006 15:15:37 -0500 >>> From: Daniel Jacobowitz >>> Cc: Vladimir Prus , gdb@sources.redhat.com >>> >>> The real problem here is that Vladimir is trying to parse the >>> result of >>> -data-evaluate-expression, which is defined as opaque. Maybe >>> someone >>> should design a major interface change where values are returned as >>> varobjs instead of strings. >> >> Maybe, I don't know. If the results of -data-evaluate-expression are >> designed to be unparsable, then indeed Vladimir shouldn't try that; >> but then there should be some way of getting that information in an >> easily parsable way. > > What a great idea! Conveniently someone else already thought of > it :-) > > -var-create - * "getpid()" > ^done,name="var1",numchild="0",type="int" > (gdb) > -var-evaluate-expression var1 > ^done,value="31989" > > (then -var-delete when you're done) > > Now, this appears at first no different. It has an opaque value > string. And for functions it has the annoying {int (int)}. But > I think we've agreed that we can remove that, and for compound > values you can decompose it using -var-list-children, and you can > query > its formatted type separately: > > -var-info-type var1 > ^done,type="int" > > For the record, it evaluates the call at -var-create time rather than > -var-evaluate-expression, as I would hope. The result is somewhat > strange if GDB hits a breakpoint while doing so. > > -- > Daniel Jacobowitz > CodeSourcery