This is the mail archive of the gdb-patches@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: GDB C plugin system, and STL container viewer as an example


On Friday 23 May 2008 20:31:47 Vincent Benony wrote:
> Le vendredi 23 mai 2008 Ã 18:43 +0400, Vladimir Prus a Ãcrit :
> 
> > 
> > What happens for vector< vector<int> >? It does not seem like you handle the
> > inner items.
> > 
> 
> I do, my plugin can handle this kind of STL type imbrication.

Can you clarify how? Suppose I have varobj V, of vector <vector<int> > type.
V has two children, V.0 and V.1, which are both empty. The first child is
resized and -var-update V is send to GDB.

If I read your patch correctly, then you'll only check V itself -- I don't
see where the V's children will be updated. Can you point me at the code.

> > > 
> > > It seems to work well into KDevelop 
> > 
> > Strange, I don't know any codepath in KDevelop 3.5 that could possible handle this.
> > Which version did you try with?
> > 
> 
> 3.5.1
> 
> indeed, it seems there is a problem with KDevelop
> 
> If you try a very simple project like that :
> 
> #include <vector>
> 
> int main(int, char **)
> {
> 	std::vector<int> v;
> 	ïv.push_back(1);
> 	ïv.push_back(2);
> 	ïv.push_back(3);
> 	ïv.push_back(4);
> 	v[2]=5;
> 	*(v.begin()) = 6;
> 	return 0;
> }
> 
> 	in KDevelop, place a breakpoint on the "v.push_back(2);" line, add a
> watch expression to 'v'.
> 
> 	Expand local and watch views of 'v' variable. Then step line by line,
> and you'll see that 'watch' part is correctly updated, 

This is because all versions of GDB except for CVS HEAD is uncapable of properly
supporting watches via MI interface. As result, KDevelop has to reevaluate watches
at each step, which probably leads to this "workiness"

> whereas 'local' 
> part is not.
> 
> 	Could it be fixed by something in my GDB patch, or is it a KDevelop
> problem, ie does KDevelop assumes that an array never changes its size ?

Current version of MI assumes so -- there's no way to say that the number of
children has changed, and nothing says that if a variable object is reported
as changed, the frontend is required to re-get the list of children. 

- Volodya


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