From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24740 invoked by alias); 5 Feb 2008 12:03:39 -0000 Received: (qmail 24731 invoked by uid 22791); 5 Feb 2008 12:03:38 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Feb 2008 12:03:21 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1JMMW8-0007TK-AG for gdb@sources.redhat.com; Tue, 05 Feb 2008 15:03:17 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JMMVs-0007Sx-U9; Tue, 05 Feb 2008 15:02:57 +0300 From: Vladimir Prus To: Mark Kettenis Subject: Re: Variable objects and STL containers Date: Tue, 05 Feb 2008 12:03:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <18343.64413.689019.489727@kahikatea.snap.net.nz> <200802051131.m15BV7kd006854@brahms.sibelius.xs4all.nl> In-Reply-To: <200802051131.m15BV7kd006854@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802051502.58463.ghost@cs.msu.su> 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-02/txt/msg00021.txt.bz2 On Tuesday 05 February 2008 14:31:07 Mark Kettenis wrote: > > From: Vladimir Prus > > Date: Tue, 05 Feb 2008 09:16:53 +0300 > > > > Technically, there is formal interface, called iterators, provided by the > > C++ standard. I don't have the slightest confidence in gdb not falling over > > if you try to use them, though. > > That means that you actually have to call functions in the inferior, > which might modify state you don't want to modify. In theory, all called functions are supposed to be const member functions, so should not modify anything. In practice, they might still touch some memory (if that does not modify logical state of the object), and if we're trying to calling functions on non-yet-initialized object, that might corrupt things. (And IIUC, gcc still won't tell us when a C++ object is initialized). > And of course it > doesn't work at all for core dumps. Yes. > > We discussed using Python scripting for that; in fact, I have a patch locally > > that will make > > > > -var-evaluate-expression V > > > > for a vector print something like: > > > > [1,2,3] > > > > I'm working on making those element the children of the variable object, > > but it's not done yet. > > Still this means that you'll need to write python code for each and > every STL implementation, and play catchup whenever the implementation > is changed. In case of std::vector in GCC, I doubt many changes are coming. > I guess the only way to get this to work is to connvince > the GCC people to maintain the python code together with libstdc++. Of course that would be ideal. However, libstdc++ is not the only standard library, and anyway -- having the mechanism is more important that who gets to write python code. - Volodya