Re: MI & pretty-printing

Vladimir Prus
2009-08-15T20:43:37Z

[-- 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;
}