This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: type prefixes for values


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]