From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32407 invoked by alias); 23 Apr 2008 07:28:17 -0000 Received: (qmail 32394 invoked by uid 22791); 23 Apr 2008 07:28:15 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 07:27:52 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 0A7FC2081D for ; Wed, 23 Apr 2008 09:27:48 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id E1DC72081A for ; Wed, 23 Apr 2008 09:27:47 +0200 (CEST) From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb@sourceware.org Subject: Re: Python/MI/STL visualization Date: Wed, 23 Apr 2008 10:09:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200804230006.55278.vladimir@codesourcery.com> In-Reply-To: <200804230006.55278.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804230929.19011.apoenitz@trolltech.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00194.txt.bz2 On Tuesday 22 April 2008 22:06:54 Vladimir Prus wrote: > Hi, Hi Vladimir. > I've just implement the logic for computing the children of MI varobj > using Python scripts. Using the attached .gdbinit, I can do the following: > > -var-create V * v > ^done,name="V",numchild="1",value="{...}",type="std::vector >" > (gdb) > -var-set-visualizer V VectorVisualizer > ^done > (gdb) > -var-list-children --all-values V > ^done,numchild="2",children=[ > child={name="V.0",exp="0",numchild="0",value="1",type="int"}, > child={name="V.1",exp="1",numchild="0",value="2",type="int"}] Nice. [Btw, one thing I do when dumping large MI-style data is to ^done,numchild="2",childtyp="int",childnumchild="0",children=[ child={name="V.0",exp="0",value="1"}, child={name="V.1",exp="1",value="2"}] Not exactly good syntax but reduces communication effort which shows when dumping large amount of data over a slow connection especially if the 'childtype' is something lengthy ;-). I'd argue it makes even the output better readable for human inspectors.] > Previously, we discussed how to best report the case where the number of children of > varobj changes. The approach I've implemented is for -var-update to report the varobj > that had the number of children changed, and include the new 'children' attribute > for that varobj. So, if I had a vector of 1 element and push another other, I get > this: > > -var-update V > ^done,changelist=[{name="V",in_scope="true",type_changed="false", > children=[{name="V.0",exp="0",numchild="0",type="int"}, > {name="V.1",exp="1",numchild="0",type="int"}]}] > > I like this approach because it does not assume that children are added or removed > at back -- if the list of children change, we report the entire new list, and can > put new varobj in the middle. > > On Python level, visualization is handled by a Python class instance -- one instance > per varobj. This approach, as opposed to a function, allows Python code to do > whatever caching it sees fit. > > Of course, there are quite some issues and questions: > > 1. Vectors can get large, and getting them can get slow. Do we want to have > incremental fetch of some kind? On UI level, I'm thinking of something > like KDevelop's incremental fetch of frames, see > http://vladimir_prus.blogspot.com/2007/02/debugger-stories-stack-widget.html > But we also need MI level support. Specifying a 'child range' might do the trick. Maybe -var-set-child-range V -var-set-child-range V * /* reset */ or such, and whenever data is reported, only children in the range ... are reported. > 2. Presumably, it's better to automatically assign visualizers to varobjs > of specific types. What's the best way to specify 'all vectors'. Does > using regexps seem good enough? I would think so. It is nice when one can distinguish three cases (simple type, pointers, "the rest"), and this should be possible with regexps. > 3. One can have vector of vectors. However, present code requires the visualizers > be explicitly set for each element of the outer vector. Should be have some way to > set visualizers on all future children of a given varobj? I'm not quite sure > how std::map will be presented, but probably we will have children of different > types. Then, should we have a way to set visualizers on all future children of > specific type. I think visualizers are best set _by type_, not by var object. It's hard to imagine a scenario where this is not wanted. > 4. We still have the problem that GCC debug information will say that variable > exists even before the constructor for that variable has run. So, creating > robust visualizer is rather hard. Anybody knows if we can workaround this? Well, I run "visualizer code" injected into the inferior and trigger it with gdb's "call". I do not even try to make them robust after noticing that there is not enough information available. But simply letting them crash and handling the segfault works rather nicely as far as I can tell ;-) > I think even comparing declaration line with the current line is better than > nothing. "Nothing" might be ok ;-) Andre'