From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1760 invoked by alias); 23 Apr 2008 09:59:44 -0000 Received: (qmail 1750 invoked by uid 22791); 23 Apr 2008 09:59:43 -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 09:59:23 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 7514C20AFF for ; Wed, 23 Apr 2008 11:59:21 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 5C7C820AA7 for ; Wed, 23 Apr 2008 11:59:21 +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:55:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200804230006.55278.vladimir@codesourcery.com> <200804230929.19011.apoenitz@trolltech.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804231200.52610.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/msg00196.txt.bz2 On Wednesday 23 April 2008 09:46:07 Vladimir Prus wrote: > >> 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. > > Or adding range parameter to -var-list-children. In either case, I'm not yet sure > how to make Python interface support this. Of course, we can always make python > side use iterators, which will work for the case where we fetch more children at > the end. Or that ;-) > [...] > >> 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 ;-) > > Well, segfaul is not scary. What is scary is if due to uninitialized data, > the amount of the children the visualizer wants to fetch end up been 10000 :-) Indeed. My "solution" here is to wildly poke around in the structure hoping to trigger a segfault early and interpret such segfault as "uninitialized object". So if there's a std::vector<> with size() reporting a non-0 value, try to access the first and last element and one from the middle and hope that at least one of these addresses are "bad" ;-) In practice, this works rather nicely. The bigger the reported size() gets the more potential harm would actually listing the children do, but the more likely it also is to recognize the object as uninitialized. Of course, not having to play such "games" would be much nicer ;-} Andre'