Re: MI: type prefixes for values

Jim Ingham
2006-02-17T20:41:12Z

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