From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20889 invoked by alias); 11 Feb 2008 09:12:16 -0000 Received: (qmail 20880 invoked by uid 22791); 11 Feb 2008 09:12:15 -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; Mon, 11 Feb 2008 09:11:56 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1JOUhX-0000k5-Uh for gdb@sources.redhat.com; Mon, 11 Feb 2008 12:11:53 +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 1JOUhO-0000jj-79; Mon, 11 Feb 2008 12:11:38 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: Variable objects and STL containers Date: Mon, 11 Feb 2008 09:12: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> <200802101010.49506.ghost@cs.msu.su> <18351.26207.310382.539746@kahikatea.snap.net.nz> In-Reply-To: <18351.26207.310382.539746@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802111211.36848.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/msg00055.txt.bz2 On Monday 11 February 2008 00:02:23 Nick Roberts wrote: > > > > I anticipate that -var-update will: > > > > > > > > 1. Create new children, and report them. > > > > 2. Report children that are now gone, possibly deleting them. > > > > > > That sounds sensible. Discussion on the gcc mailing list suggested that > > > this should all be done in GDB, i.e., in C. I will explore that > > > possibility. > > > > Please note that I already have proof-of-concept Python integration, > > together with code to use Python for -var-evaluate-expression, together > > with not-yet-working patch to dynamically compute the list of varobj children. > > It might be better to wait till I got the last bit done. > > Will the Python integration be self contained or does it require separate > libraries? To use Python you'd need a Python interpreter library. > Will it restrict the number of platforms that GDB builds on? If you don't have Python, Python support won't be compiled. > In any case, there seem to be two projects here: Python integration and the > display of STL containers using variable objects. It's not clear to me that > the former is necessary for the latter. Well, I have patches in the works for both. > Below is just a quick sketch of the thoughts I have, which may or may not be > sensible. > > In the case of vectors, var->num_children would be computed from n = > v._M_impl._M_finish - v._M_impl._M_start and the children would be created from > *(v._M_impl._M_start+1), *(v._M_impl._M_start+2), ...*(v._M_impl._M_start+n). I think it should be: *(v._M_impl._M_start+0),...,*(v._M_impl._M_start+n-1). > I guess a special variable object would need to be created for n and when it > was reported as changed bt -var-update, new/old variable objects could > accordingly be created/deleted. I don't see why we need a separate variable object. If the number of children of a variable object changes, then -var-update can include that variable object in the result (and tell the new number of children). Now the question is whether the children that are no longer present should be deleted, and whether new children should be auto-created. It is probably better to auto-delete varobjs corresponding to the children that are gone. Then, -var-update output will list those children, with 'in_scope' attribute mentioning varobj is gone. Frontend is most likely to want those varobjs to be gone, and doing this automatically saves frontend complexity. Note that even if frontend wants to hold to the value of now-deleted child, for some reason, it must do it explicitly. Suppose that we don't auto-delete children, and the number of children first decreases by one and then increases by one. The varobj that corresponds to the last original child now is not accessible in any way. It's not accessible via children list of it's parent. It's not accessible by the name -- as the name got reused when new child is added. So, we cannot even get the value of that varobj. I think that likewise, -var-update should create varobjs for new children, and return them -- we probably need a new attribute to indicate that a varobj was just created. This might sound like breaking frontends not prepared to see new varobjs in -var-update output. However, this dynamic child behaviour will happen only as result of explicit request from frontend. It's natural to give frontend a choice between 'raw' representation and 'pretty' representation, and for compatibility, it's best to default to 'raw'. And if frontend asks gdb to use pretty representation for a varobj, or all varobj of given type, we can expect the frontend to property handle auto-created varobjs. Does this make sense? - Volodya