This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: adding support for ptype to MI
Dodji Seketeli wrote:
> 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
>> information.
>>
>> 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.
Do you have concrete numbers?
> 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
> most distros.
Did you report those problems?
> 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'm sorry, I don't see such need yet. My biggest concern is that you start
with using -data-evaluate-expression, which is known to provide output that
ambiguous, hard to parse, and subject to change without notice. Then, you ask
for a command to simplify working with that command. Instead of that, we should
first figure what problems you have with -var-* commands and if those are
fixeable.
- Volodya