Re: adding support for ptype to MI

[Vladimir Prus <vladimir at codesourcery dot com>]

Rick Moseley wrote:

> Hi all,
> 
> During a recent back-and-forth with some developers it was pointed out
> that one of the things holding back some of the GUI work for gdb was
> that MI does not support the "ptype" command. (There may already be a
> bug filed for this I'm told, but perusing the gdb bugzilla data base I
> don't see it.)  The inability to get output in usable formats from this
> command(and maybe others) has kept the gdb GUI's from offering features
> that Visual C++ and other Windows-based GUI's provide with their debuggers.
> 
> One of the good suggestions(from Dodji Seleteli who has done a *lot* of
> work on the Nemiver project) suggests gdb might respond to some MI
> requests with a "serialized object".  Here is his opinion:
> 
> 
> "I think my main problem with type printing in MI is that there is no
> way in MI today to get a description of a type returned as a "serialized
> object". By serialized object I mean each type should be represented in
> a hierarchical way so that the UI can represent it as a tree to the
> user, letting her browse the type fields and giving her a chance to
> drill down/up there. A bit like what you get when you do
> "-data-evaluate-expression <variable-name>" in MI.
> 
> Instead, today, one has to resort to the "ptype" command (which is not
> part of MI) that returns a plain string representing the type. That's
> too rough and make us lag behind what you get in say visual-c++ on windows.
> 
> Also, in that hierarchical view that I'd like, I MI should annotate the
> types so that the debugging client (the UI) can know a given field is a
> pointer to type foo so that it can propose better de-referencing."
> 
> 
> One of the things the archer project would like to do is provide better
> information via MI to the various gdb UI's.  Maybe there are other
> commands that would be useful to MI or existing commands that could
> provide more useful information.  Being new to the gdb project and
> unfamiliar with the past history of this subject I would like to get
> some comments/ideas on this(maybe this has been discussed on some thread
> before).  I would like to get a good problem definition (or several
> problem definitions if need be) of this and put this item in the archer
> project queue if most everyone agrees this is a good idea.

I'm afraid that your email lacks the most crucial bit of information -- the use
case that's hard to implement with current MI. Can you provide one?

- Volodya