Re: Patch: implement new dynamic varobj spec

Nick Roberts
2009-09-14T22:55:03Z

> I think we've been conservative enough about this code that it is
> probably reasonable to let people rely on it. It has been through a lot
> of vetting.
>
> However, I don't mind adding a note to the manual if other maintainers
> want that.

Some of the the headaches of MI are due to legacy code. Hence mi0, mi1, mi2,
etc. I don't know if others are already using these features but it would
seem sensible to me for frontends to _drive_ MI and not for it to be the other
way around. For example, here are a couple changes that I would like to see:

1) The displayhint field output from -var-create as well/or instead of from
-var-list-children. That would be useful for determining whether an element
should be expandable or not. Types map, list -- yes, type string -- no.
With normal variable objects I just use num_children but this isn't sufficient
for dynamic ones.

2) If is_map is true, rather than:

var1.0 = key0
var1.1 = value0
var1.2 = key1
var1.0 = vaue1
...

I would prefer GDB to output:

var1.0 = "map_element"
var1.0.key = key0
var1.0.value = value0
var1.1 = "map_element"
var1.1.key = key1
var1.1.value = value1

That way the values could be displayed as a tree:

[-]--0
| |
| |--key0
| |
| |--value0
|
[-]--1
| |
| |--key1
| |
| |--value1

--
Nick http://www.inet.net.nz/~nickrob