From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7117 invoked by alias); 11 Feb 2008 20:28:24 -0000 Received: (qmail 7106 invoked by uid 22791); 11 Feb 2008 20:28:23 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 11 Feb 2008 20:27:50 +0000 Received: from kahikatea.snap.net.nz (110.30.255.123.static.snap.net.nz [123.255.30.110]) by viper.snap.net.nz (Postfix) with ESMTP id 9A8263DA19F; Tue, 12 Feb 2008 09:27:41 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 34DDA8FC6D; Tue, 12 Feb 2008 09:27:40 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18352.44987.636658.377672@kahikatea.snap.net.nz> Date: Mon, 11 Feb 2008 20:28:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Variable objects and STL containers In-Reply-To: <200802111211.36848.ghost@cs.msu.su> References: <18343.64413.689019.489727@kahikatea.snap.net.nz> <200802101010.49506.ghost@cs.msu.su> <18351.26207.310382.539746@kahikatea.snap.net.nz> <200802111211.36848.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.1.90.2 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-02/txt/msg00062.txt.bz2 > > 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. So if you don't have Python, your patch for variable objects for STL containers will not work. > > 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. Can they be presented separately? > > 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). Yes. > > 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). I just think it might mean that the output of -var-update need not change. If n changes the frontend can create/delete the extra/old variable objects. > 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. I think it may involve a bigger change to the MI output. > 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 don't think we should worry about keeping the value of STL members that have been deleted - at least for now. > 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. AFAIK, if three new members are created and two deleted, all the executable needs to know is that there is one new member. That's why I think it may be simple to just have a special variable object that tells the front end when the number of members changes. > 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. An option for this sounds like a good idea. > Does this make sense? Overall, it does. I think it would be a good idea to allow room for possible changes in implementation detail. -- Nick http://www.inet.net.nz/~nickrob