This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB C plugin system, and STL container viewer as an example
- From: Vincent Benony <vbenony at nordnet dot fr>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 23 May 2008 16:32:38 +0200
- Subject: Re: GDB C plugin system, and STL container viewer as an example
- References: <1211535909.8253.16.camel@bsr-desktop> <g16jrk$3r6$1@ger.gmane.org>
> I don't see how you report that fact that the number of children of a
> varobj has changed. Without that, I'm not sure how useful MI display
> of vectors is. Am I missing something?
>
> - Volodya
this is done by lines 1157 to 1166 of varobj.c
if (plugins_type_handled(varobj_get_gdb_type(*varp)))
{
int new_childs = plugins_get_num_children(*varp);
if (new_childs != (*varp)->num_children)
{
(*varp)->num_children = new_childs;
(*varp)->children = varobj_list_children (*varp);
VEC_safe_push (varobj_p, result, *varp);
}
}
I evaluate the number of children at each update, and I compare with the
current number of childs stored in the varobj structure, if different,
object is added to update list.
It seems to work well into KDevelop and Insight/GDB, ie if I step in my
source code, I can see children items beeing added at each push_back.
Only Eclipse/CDT has a problem handling a vector ïgoing from 0 to 1
child (child is not displayed, but Eclipse say that number of children
has changed, displaying the correct number ; seems like an Eclipse bug),
but it works when going from 1 to 2 children, or more...