MI: type prefixes for values

[Jim Ingham]

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 <drow@false.org>
>>> Cc: Vladimir Prus <ghost@cs.msu.su>, 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