This is the mail archive of the
mailing list for the Archer project.
Re: adding support for ptype to MI
- From: Dodji Seketeli <dseketel at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: Rick Moseley <rmoseley at redhat dot com>, Project Archer <archer at sourceware dot org>
- Date: Fri, 15 Aug 2008 14:48:47 +0200
- Subject: Re: adding support for ptype to MI
- Organization: Red Hat
- References: <48A49A5C.firstname.lastname@example.org> <48A49FE2.email@example.com>
Keith Seitz wrote:
I'm afraid I don't understand what the problem is. Varobj certainly
provides a hierarchical view of variables, and that includes type
Is that developers want just type information (e.g., for a type
browser/inspector kind of thing)? In which case I would expect
"-var-create - * (TYPE)0" to work. Alas, I see that is now broken.
There are times where you don't necessarily want to resort to varobjs.
For instance, if I can parse the result of "-data-evaluate-expression
<variable-name>" _quickly enough_, using it incurs less latency than
using varobjs. At the end of that, that results into a snappier UI for
the user. And to me, that's a feature.
Also, as varobjs have to be managed per frame - you have to delete them
when you leave a frame and that obliges you to send MI commands each
time you enter a new frame anyway - they obliges the client to do book
keeping. At least in the current versions of GDB that are shipped on
So quickly doing -data-evaluate-expression <variable-name> does have its
need. Similarly, the hypothetical -data-print-type <variable-name> that
I'd like to see has its need as well.
I am not saying that varobjs are useless. But I think being able to
print the type of a variable, fully, and get the result as a serialized
object can be very very useful.