This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
adding support for ptype to MI
- From: Rick Moseley <rmoseley at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 14 Aug 2008 15:49:32 -0500
- Subject: adding support for ptype to MI
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.
Thanks,
Rick