This is the mail archive of the gdb@sourceware.org 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]

Re: Python API - nested pretty printers MI implications


On Monday 15 August 2011 13:36:50, André Pönitz wrote:

> I am not sure how partial updates on MI varobjs with phony levels 
> would work at all. 
> 
> Imagine a data structure containing a  char m[1000000][10], and a 
> "phony level pretty printer" that displays all the m[i] with m[i][0] == 'A'.
> Suppose initially that would be the items m[1] and m[10000], so we 
> get a display like 
> 
>    m --
>       m[1]  "A...."
>       m[1000]   "A...."
> 
> Now the user steps over m[5000][0] = 'A'. Assuming there is no dummy
> varobj for every _potential_ child, what mechanism would trigger the 
> varobj's update to produce the display
> 
>    m --
>       m[1]  "A...."
>       m[5000]   "A...."
>       m[10000]   "A...."     
> 
> eventually?

AFAIK, frontends do:

-var-update 2 *

and that should yield (but doesn't):

^done,changelist=[{name="var1.m",value="",in_scope="true",type_changed="false",new_num_children="1",has_more="0",new_children=[{name="var1.m.5000",exp="5000",numchild="1",value="A....",type="foo"}]}]
(gdb)

Note new_num_children.  This should trigger the frontend re-fetching
the children of var1.m.

I think the issue here is that dynamic varobj's code doesn't
handle new children appearing before existing ones.  I got a 
patch to address that though, needed for supporting varobj's
that hide "<unavailable>" children.

-- 
Pedro Alves


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