MI & pretty-printing

MI & pretty-printing

[Vladimir Prus]

On IRC, Tom and I talked about best way to support Python
pretty-printing with MI. Here's my attempt at summarizing.

1. It does not seem like existing frontends can make use of
pretty-printing automatically. If frontend tries to list
children of an invalid value, GDB may just hang. If GDB
automatically limits the number of children, then existing
frontends will not be able to see the children beyond this
limit (or have GUI for that). Therefore, it is suggested than
a new MI command is used to explicitly enable pretty-printing
in MI, say 

	-enable-pretty-printing [0|1]

2. The FE may request a specific range of children by passing
low and high boundary:

    -var-list-children varobj [low] [hi]

If no range is specified, an attempt to report all children is
made, be what may.

3. A varobj keeps a range of children to fetch on -var-update, and
a new command is added to set that range, say,

    -var-set-update-range varobj low hi

The important aspect is that the range updated by -var-update is
not automatically changed by -var-list-children. This allows the
frontend to implement any update strategy it wishes, for example:

- Frontend might initially set update range to 0-10 and also
fetch first 10 children. If user wishes to see 10 children more,
frontend does -var-list-children 10 20. On next step, -var-update
updates first 10 children, the remaining ones are discarded.

- Frontend might display a part of big array, say from 1000th to 1100th
elements. User scrolls. FE does:

	-var-list-children varobj 1100 1110

to fetch 10 more items, and then does

    -var-set-update-range varobj 1010 1110

so that the entire view is updated on next step.

This actually seem almost same as Tom's original design, except that
-var-list-children does not automatically change the update range.

Since this is somewhat contrived area, I am not 100% sure the above is
best solution -- feedback appreciated.

- Volodya

MI & pretty-printing

[Nick Roberts]

Vladimir Prus writes:
 > 
 > On IRC, Tom and I talked about best way to support Python
 > pretty-printing with MI. Here's my attempt at summarizing.
 > 
 > 1. It does not seem like existing frontends can make use of
 > pretty-printing automatically. If frontend tries to list
 > children of an invalid value, GDB may just hang. If GDB
 > automatically limits the number of children, then existing
 > frontends will not be able to see the children beyond this
 > limit (or have GUI for that). Therefore, it is suggested than
 > a new MI command is used to explicitly enable pretty-printing
 > in MI, say 
 > 
 > 	-enable-pretty-printing [0|1]
 > 
 > 2. The FE may request a specific range of children by passing
 > low and high boundary:
 > 
 >     -var-list-children varobj [low] [hi]

When I submitted patches for similar functionality in April/May
of last year, I proposed a third parameter, stride, or step size,
to sample a large array.  ISTR Solaris dbx and Totalviewallow(ed) allow
printing array slices in this way.

first patch: http://sourceware.org/ml/gdb-patches/2008-04/msg00493.html
final patch: http://sourceware.org/ml/gdb-patches/2008-05/msg00328.html

 > If no range is specified, an attempt to report all children is
 > made, be what may.
 > 
 > 3. A varobj keeps a range of children to fetch on -var-update, and
 > a new command is added to set that range, say,
 > 
 >     -var-set-update-range varobj low hi

I think -var-set-update-range would be a useful addition.

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

Re: MI & pretty-printing

[Vladimir Prus]

On Tuesday 14 July 2009 Nick Roberts wrote:

> Vladimir Prus writes:
>  > 
>  > On IRC, Tom and I talked about best way to support Python
>  > pretty-printing with MI. Here's my attempt at summarizing.
>  > 
>  > 1. It does not seem like existing frontends can make use of
>  > pretty-printing automatically. If frontend tries to list
>  > children of an invalid value, GDB may just hang. If GDB
>  > automatically limits the number of children, then existing
>  > frontends will not be able to see the children beyond this
>  > limit (or have GUI for that). Therefore, it is suggested than
>  > a new MI command is used to explicitly enable pretty-printing
>  > in MI, say 
>  > 
>  > 	-enable-pretty-printing [0|1]
>  > 
>  > 2. The FE may request a specific range of children by passing
>  > low and high boundary:
>  > 
>  >     -var-list-children varobj [low] [hi]
> 
> When I submitted patches for similar functionality in April/May
> of last year, I proposed a third parameter, stride, or step size,
> to sample a large array.  ISTR Solaris dbx and Totalviewallow(ed) allow
> printing array slices in this way.
> 
> first patch: http://sourceware.org/ml/gdb-patches/2008-04/msg00493.html
> final patch: http://sourceware.org/ml/gdb-patches/2008-05/msg00328.html

Right, I remember. However, I am still not sure were are ready for that addition.
We don't even have single range fully implemented *and* tested with real frontend.
Stride might be a good addition, but better not be done until we're done the current
round of changes.

>  > If no range is specified, an attempt to report all children is
>  > made, be what may.
>  > 
>  > 3. A varobj keeps a range of children to fetch on -var-update, and
>  > a new command is added to set that range, say,
>  > 
>  >     -var-set-update-range varobj low hi
> 
> I think -var-set-update-range would be a useful addition.

OK.

- Volodya

Re: MI & pretty-printing

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> On IRC, Tom and I talked about best way to support Python
Volodya> pretty-printing with MI. Here's my attempt at summarizing.

I finally finished the first draft of this.  I pushed it to the
archer-tromey-python branch today.  Please give it a try; if it is all
looking ok I will extract it and push it into CVS.

Volodya> 	-enable-pretty-printing [0|1]

I omitted the argument in my implementation.

I didn't see a benefit to letting MI clients disable pretty-printing
globally.  They can do it per-varobj, or simply not send this command in
the first place.  (If we did allow this, then we'd have to define what
it meant for existing varobjs with printers installed.)

Volodya>     -var-list-children varobj [low] [hi]
Volodya>     -var-set-update-range varobj low hi

I implemented these verbatim.

There is now an optional has_more attribute on varobj output; it is a
boolean which is "1" if there seem to be children past the last
requested child.

The "numchild" attribute is now a bit funny.  It can't tell the actual
number of children, only the number you've requested.  It may be smaller
than the range you requested.  The user has to pay attention to this,
because it is the only way to notice that children were deleted (for
-var-update, this will show up in new_num_children).

When doing a -var-update, a dynamic varobj may report "new_children".
This is a list of any new children added during this update.  New
children can only be added at the end of the update range (changes to
existing elements are reported as changed varobjs).

I haven't documented all these details yet.  I'll do that soon.
(FWIW, -var-update seems under-documented in general.)

Tom

Re: MI & pretty-printing

[Vladimir Prus]

On Friday 07 August 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> On IRC, Tom and I talked about best way to support Python
> Volodya> pretty-printing with MI. Here's my attempt at summarizing.
> 
> I finally finished the first draft of this.  I pushed it to the
> archer-tromey-python branch today.  Please give it a try; if it is all
> looking ok I will extract it and push it into CVS.

Thank you. I'll give it a try on Monday.

- Volodya

Re: MI & pretty-printing

[Vladimir Prus]

[-- Attachment #1: Type: Text/Plain, Size: 5623 bytes --]

On Friday 07 August 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> On IRC, Tom and I talked about best way to support Python
> Volodya> pretty-printing with MI. Here's my attempt at summarizing.
> 
> I finally finished the first draft of this.  I pushed it to the
> archer-tromey-python branch today.  Please give it a try; if it is all
> looking ok I will extract it and push it into CVS.

Tom,
I have tried this. Basic vector<int> display works fine. I have run
into a couple of issues. Please see the attached test program and a
session below:

	(gdb)
	-enable-pretty-printing
	^done
	(gdb)
	-break-insert test.cpp:9
	^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048877",
	func="main",file="test.cpp",fullname="/home/ghost/Build/test/test.cpp",line="9",times="0",original-location="test.cpp:9"}
	(gdb)
	-exec-run
	=thread-group-created,id="26265"
	=thread-created,id="1",group-id="26265"
	^running
	*running,thread-id="all"
	(gdb)
	=library-loaded,id="/lib/ld-linux.so.2",target-name="/lib/ld-linux.so.2",host-name="/lib/ld-linux.so.2",symbols-loaded="0"
	=library-loaded,id="/usr/lib/libstdc++.so.6",target-name="/usr/lib/libstdc++.so.6",host-name="/usr/lib/libstdc++.so.6",symbols-loaded="0"
	=library-loaded,id="/lib/tls/i686/cmov/libm.so.6",target-name="/lib/tls/i686/cmov/libm.so.6",host-name="/lib/tls/i686/cmov/libm.so.6",symbols-loaded="0"
	=library-loaded,id="/lib/libgcc_s.so.1",target-name="/lib/libgcc_s.so.1",host-name="/lib/libgcc_s.so.1",symbols-loaded="0"
	=library-loaded,id="/lib/tls/i686/cmov/libc.so.6",target-name="/lib/tls/i686/cmov/libc.so.6",host-name="/lib/tls/i686/cmov/libc.so.6",symbols-loaded="0"
	*stopped,reason="breakpoint-	hit",disp="keep",bkptno="1",frame={addr="0x08048877",
	func="main",args=[],file="test.cpp",fullname="/home/ghost/Build/test/test.cpp",line="9"},thread-id="1",stopped-threads="all"
	(gdb)
	-var-create v * v
	^done,name="v",numchild="-1",value="{...}",type="std::vector<int, std::allocator<int> >",thread-id="1"
	(gdb)
	-var-list-children --all-values v
	^done,numchild="1",displayhint="array",children=[child={name="v.[0]",exp="[0]",numchild="0",value="10",type="int",thread-id="1"}],has_more="0"
	(gdb)
	-exec-next
	^running
	*running,thread-id="1"
	(gdb)
	*stopped,reason="end-stepping-range",frame={addr="0x08048890",func="main",args=[],file="test.cpp",fullname="/home/ghost/Build/test/test.cpp",line="11"}
	(gdb)
	-var-update --all-values *
	^done,changelist=[{name="v",value="std::vector of length 2, capacity 2",in_scope="true",type_changed="false",new_num_children="2",
	displayhint="array",has_more="0",new_children=[{name="v.[1]",exp="[1]",numchild="0",value="11",type="int",thread-id="1"}]}]
	(gdb)

Note that at this point, displayed value of the vector switches to "std::vector of length 2...".
I think we discussed that such value should not be used inside MI.

	-break-insert test.cpp:14
	^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804891d",func="main",
    file="test.cpp",fullname="/home/ghost/Build/test/test.cpp",line="14",times="0",original-location="test.cpp:14"}
    (gdb)
    -exec-continue
    ^running
    *running,thread-id="all"
    (gdb)
    *stopped,reason="breakpoint- 
    hit",disp="keep",bkptno="2",frame={addr="0x0804891d",func="main",args=[],file="test.cpp",fullname="/home/ghost/Build/test/test.cpp",line="14"},thread-
    id="1",stopped-threads="all"
    (gdb)
    -var-create v2 * v2
    ^done,name="v2",numchild="-1",value="{...}",type="std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,  
    std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >",thread-id="1"
    (gdb)
    -var-list-children --all-values v2
    ^done,numchild="1",displayhint="array",children=[child={name="v2.[0]",exp="[0]",numchild="-1",value="{...}",type="std::basic_string<char,  
    std::char_traits<char>, std::allocator<char> >",thread-id="1"}],has_more="0"
    (gdb)
    -var-list-children --all-values v2.[0]
    Segmentation fault

There are two problems here. First, the elements of vector<string> should be subject to pretty-printing
too (and should have zero children). Second, this should not crash.

 
> Volodya> 	-enable-pretty-printing [0|1]
> 
> I omitted the argument in my implementation.

This is fine.

> Volodya>     -var-list-children varobj [low] [hi]
> Volodya>     -var-set-update-range varobj low hi
> 
> I implemented these verbatim.
> 
> There is now an optional has_more attribute on varobj output; it is a
> boolean which is "1" if there seem to be children past the last
> requested child.
> 
> The "numchild" attribute is now a bit funny.  It can't tell the actual
> number of children, only the number you've requested.  It may be smaller
> than the range you requested.  The user has to pay attention to this,
> because it is the only way to notice that children were deleted (for
> -var-update, this will show up in new_num_children).

Is it expected that if I have varobj with 1 child, then 

   -var-list-children var 10 20

still prints numchild=1 ?

> When doing a -var-update, a dynamic varobj may report "new_children".
> This is a list of any new children added during this update.  New
> children can only be added at the end of the update range (changes to
> existing elements are reported as changed varobjs).
> 
> I haven't documented all these details yet.  I'll do that soon.
> (FWIW, -var-update seems under-documented in general.)

Yes, I am planning to document that a bit more.

Thanks,
Volodya


> 
> Tom
> 

[-- Attachment #2: test.cpp --]
[-- Type: text/x-c++src, Size: 203 bytes --]


#include <vector>
#include <string>

int main()
{
    std::vector<int> v;
    v.push_back(10);
    v.push_back(11);
    
    std::vector<std::string> v2;
    v2.push_back("hi");
    
    return 0;    
}

Re: MI & pretty-printing

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> Note that at this point, displayed value of the vector switches
Volodya> to "std::vector of length 2...".  I think we discussed that
Volodya> such value should not be used inside MI.

We discussed it but, IIRC, did not come to any agreement about it.

Volodya> Is it expected that if I have varobj with 1 child, then 
Volodya>    -var-list-children var 10 20
Volodya> still prints numchild=1 ?

I don't know.  I suppose we could try to restrict it to children in the
requested range.

Tom

Re: MI & pretty-printing

[Vladimir Prus]

On Monday 17 August 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> Note that at this point, displayed value of the vector switches
> Volodya> to "std::vector of length 2...".  I think we discussed that
> Volodya> such value should not be used inside MI.
> 
> We discussed it but, IIRC, did not come to any agreement about it.

Hmm, I though we decided that some hint to pretty-printers is desirable.
Anyway, let me repeat my point -- the descriptive string is rather long,
so might not fit in variables window. Further, a frontend typically
has some way to display variable type already, so "std::vector" part 
of the string is not helping either. So, I'd much rather have {...} for
all composite types in MI.

> Volodya> Is it expected that if I have varobj with 1 child, then 
> Volodya>    -var-list-children var 10 20
> Volodya> still prints numchild=1 ?
> 
> I don't know.  I suppose we could try to restrict it to children in the
> requested range.

I don't know either. The current behaviour *feels* strange, but then my
WIP patch for kdevelop does not use this field at all, for incremental
fetches. Maybe we can leave it as is, for now.

Any comment on the crash?

- Volodya


> 
> Tom
> 

Re: MI & pretty-printing

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Tom> We discussed it but, IIRC, did not come to any agreement about it.

Volodya> Hmm, I though we decided that some hint to pretty-printers is
Volodya> desirable.  Anyway, let me repeat my point -- the descriptive
Volodya> string is rather long, so might not fit in variables
Volodya> window. Further, a frontend typically has some way to display
Volodya> variable type already, so "std::vector" part of the string is
Volodya> not helping either. So, I'd much rather have {...} for all
Volodya> composite types in MI.

I suppose we could have dynamic varobjs with children print "{...}" here
always.  Or you could just do whatever you like in your GUI.  I hesitate
to change this because it isn't clear to me that "{...}" is a
universally good choice for all GUIs and all printers.

Volodya> I don't know either. The current behaviour *feels* strange, but then my
Volodya> WIP patch for kdevelop does not use this field at all, for incremental
Volodya> fetches. Maybe we can leave it as is, for now.

Yeah, I'm not sure if you need to watch the length for an increment
-var-list-children.  But, you definitely do for a -var-update.

Volodya> Any comment on the crash?

I fixed it.

Tom

Re: MI & pretty-printing

[Vladimir Prus]

On Tuesday 18 August 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Tom> We discussed it but, IIRC, did not come to any agreement about it.
> 
> Volodya> Hmm, I though we decided that some hint to pretty-printers is
> Volodya> desirable.  Anyway, let me repeat my point -- the descriptive
> Volodya> string is rather long, so might not fit in variables
> Volodya> window. Further, a frontend typically has some way to display
> Volodya> variable type already, so "std::vector" part of the string is
> Volodya> not helping either. So, I'd much rather have {...} for all
> Volodya> composite types in MI.
> 
> I suppose we could have dynamic varobjs with children print "{...}" here
> always. 

That's clearly one possibility.

> Or you could just do whatever you like in your GUI.

Can I? How do I know if a varobj is dynamic? ;-)

> I hesitate
> to change this because it isn't clear to me that "{...}" is a
> universally good choice for all GUIs and all printers.

I guess the most important question is that of mechanism. Right
now, we have one case (for a specific type/frontend combo) where
the string rendering of a value with children is not suitable.
There might be cases where it makes sense to use non-{...} rendering
for a type with children. Do we have a mechanism how pretty-printer
can use  different string rendering for MI and CLI?

If we don't have it now, then I'd still prefer to have all these
change be merged to FSF HEAD, without waiting for such
mechanism to be designed. But then, for now, it's better to have
the most conservative behaviour, so that frontends do not start
to depend on string rendering of varobjs with children. And {...}
seems like the most conservative thing possible. Then, if we
run into type that both have children and have string rendering
that makes sense in MI, we can introduce some solution?

> Volodya> I don't know either. The current behaviour *feels* strange, but then my
> Volodya> WIP patch for kdevelop does not use this field at all, for incremental
> Volodya> fetches. Maybe we can leave it as is, for now.
> 
> Yeah, I'm not sure if you need to watch the length for an increment
> -var-list-children.  

Well, I guess for consistency, it's best to either drop numchild from
incremental -var-list-children response, or make it report the number
of children that is actually contained in the 'children' field.

> But, you definitely do for a -var-update.

Agreed.

- Volodya

Re: MI & pretty-printing

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Tom> I hesitate to change this because it isn't clear to me that "{...}"
Tom> is a universally good choice for all GUIs and all printers.

I'm reconsidering this.  When would the immediate value of a varobj with
children be of interest?  It certainly doesn't seem to be for
non-pretty-printed varobjs.

Volodya> Do we have a mechanism how pretty-printer can use different
Volodya> string rendering for MI and CLI?

Not at present.  We could add one, of course, but I have been trying to
push the current simple design as far as it would go.  Partly this is
just stubbornness but also I do think that simplicity has some intrinsic
virtue, at least when you can get away with it.

Volodya> And {...}  seems like the most conservative thing
Volodya> possible. Then, if we run into type that both have children and
Volodya> have string rendering that makes sense in MI, we can introduce
Volodya> some solution?

Yeah.  I'll do this.

Volodya> Well, I guess for consistency, it's best to either drop numchild from
Volodya> incremental -var-list-children response, or make it report the number
Volodya> of children that is actually contained in the 'children' field.

Ok, will do.

Tom

Re: MI & pretty-printing

[Vladimir Prus]

Tom Tromey wrote:

>>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Tom> I hesitate to change this because it isn't clear to me that "{...}"
> Tom> is a universally good choice for all GUIs and all printers.
> 
> I'm reconsidering this.  When would the immediate value of a varobj with
> children be of interest?  It certainly doesn't seem to be for
> non-pretty-printed varobjs.

Well, I don't have any case at hand where immediate value would be of
*that* great value. FWIW, when I run into "too long string value"
issue I though about was to have shorter summary for vector, e.g. "[2]",
but then figured it's additional work, and folks did not complain
about "{...}" so far.

> 
> Volodya> Do we have a mechanism how pretty-printer can use different
> Volodya> string rendering for MI and CLI?
> 
> Not at present.  We could add one, of course, but I have been trying to
> push the current simple design as far as it would go.  Partly this is
> just stubbornness but also I do think that simplicity has some intrinsic
> virtue, at least when you can get away with it.

FWIW, I was driving exactly at this simplicity point :-)

> 
> Volodya> And {...}  seems like the most conservative thing
> Volodya> possible. Then, if we run into type that both have children and
> Volodya> have string rendering that makes sense in MI, we can introduce
> Volodya> some solution?
> 
> Yeah.  I'll do this.

Great, thanks!

- Volodya

Re: MI & pretty-printing

[Vladimir Prus]

Tom Tromey wrote:

>>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> On IRC, Tom and I talked about best way to support Python
> Volodya> pretty-printing with MI. Here's my attempt at summarizing.
> 
> I finally finished the first draft of this.  I pushed it to the
> archer-tromey-python branch today.  Please give it a try; if it is all
> looking ok I will extract it and push it into CVS.

Tom,

I have a couple of more questions:

1. Do you think it would be OK to make the has_more field always present?
This will allow to simplify the frontend code a bit? For non-dynamic varobjs,
it should be non-zero in var-create response if there are children.

2. Do you think it would be OK to add a special field to indicate that varobj
is dynamic? For example, if I expand a regular varobj, I probably want to
fetch every field, while for dynamic, I want to fetch just 10.

I can implement the above myself, I think, if you don't have any disagreement.

Thanks,
Volodya

Re: MI & pretty-printing

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> 1. Do you think it would be OK to make the has_more field
Volodya> always present?  This will allow to simplify the frontend code
Volodya> a bit? 

I actually did this already just to simplify the code :)

Volodya> For non-dynamic varobjs, it should be non-zero in var-create
Volodya> response if there are children.

For non-dynamic ones, numchild is correct and has_more=0 always.
This made the most sense to me.  But, we can change it if you want.

Volodya> 2. Do you think it would be OK to add a special field to
Volodya> indicate that varobj is dynamic? For example, if I expand a
Volodya> regular varobj, I probably want to fetch every field, while for
Volodya> dynamic, I want to fetch just 10.

It would be fine by me.  Just let me know what you want it to be called
and I will implement it tomorrow.

Tom

Re: MI & pretty-printing

[Vladimir Prus]

On Thursday 10 September 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> 1. Do you think it would be OK to make the has_more field
> Volodya> always present?  This will allow to simplify the frontend code
> Volodya> a bit? 
> 
> I actually did this already just to simplify the code :)
> 
> Volodya> For non-dynamic varobjs, it should be non-zero in var-create
> Volodya> response if there are children.
> 
> For non-dynamic ones, numchild is correct and has_more=0 always.
> This made the most sense to me.  But, we can change it if you want.

I though about this, and I think the current behaviour is fine.
Sorry for incoherent comments.

> Volodya> 2. Do you think it would be OK to add a special field to
> Volodya> indicate that varobj is dynamic? For example, if I expand a
> Volodya> regular varobj, I probably want to fetch every field, while for
> Volodya> dynamic, I want to fetch just 10.
> 
> It would be fine by me.  Just let me know what you want it to be called
> and I will implement it tomorrow.

I guess I need to play more with this to figure if I need it now.

Can we please have this in CVS HEAD, so that I can have other kdevelop users
bang at it?

Thanks,
Volodya

who can play?