This is the mail archive of the 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]

type description for MI

Over on -patches list, Daniel and I was discussing if MI values of variables
should include some type information, as is done on Apple branch. I'm
moving this discussion here so that it's not lost.

> >   - Port Apple change that add 'typecode' field to variable objects
> I understand why they did this, but should we really be exposing GDB's
> internal type system this way?  I'd want to see what it gets used for,
> and probably define it independently of the existing type codes.

It's hardly gdb internal type system, it's a C++ type system. You always
have pointers, functions and the same.

As for why it's used -- well, since you've used Eclipse as example recently,
take a look at org.eclipse.cdt.debug.mi.core.GDBTypeParser that goes as far
as to parse the output of "whatis" command. You probably can ask Eclipse
developer why they wrote this, but a good type system exposed via MI will
make this class unneccessary.

As an example from KDevelop, all pointer variables are shown as expandable
tree items. However, I probably don't want to do this for pointers to
functions, as a special exception. So, I need to know if a type is a
pointer to function or not.

Ideally, the type of variable will be available as tree in MI, something

  type={kind="pointer", nested={kind="class", name="MyClass", bases=[..]}}

- Volodya

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