From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6748 invoked by alias); 17 Feb 2008 20:18:39 -0000 Received: (qmail 6736 invoked by uid 22791); 17 Feb 2008 20:18:37 -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; Sun, 17 Feb 2008 20:18:11 +0000 Received: from kahikatea.snap.net.nz (194.31.255.123.static.snap.net.nz [123.255.31.194]) by viper.snap.net.nz (Postfix) with ESMTP id C607A3DA4E0; Mon, 18 Feb 2008 09:18:03 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 46A4A8FC6D; Mon, 18 Feb 2008 09:18:03 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18360.38522.477967.328610@kahikatea.snap.net.nz> Date: Sun, 17 Feb 2008 20:18:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Variable objects for STL containers In-Reply-To: References: <18354.25849.317151.537741@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.90.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00279.txt.bz2 > I don't particularly like the use of this special child to indicate > the number of children. We already have a mechanism to report the number of > children and having yet another mechanism seems just confusing. GDB needs some way to report the extra children in -var-update but I'm not worried what way is used. I wanted to establish that using gcc internals was OK and the feasibility of doing this within the C code. > Of course, if we use the existing mechanism then -var-update will have > to be able to report the variable objects that have the number of children > changed -- and a frontend will have to be adjusted to handle that mechanism. We should probably add an option to Gdb to process the STL container as a variable object in the normal way and make that the default. That also will mean we can write code for STL containers in an incremental fashion, provided we explain this in the manual. > However, it's not harder for frontend than the approach above. In fact, > using the approach above, how will frontend know that a varobj is > the special one that reports the number of children? I don't see anything > in the output above to indicate the special role of var1.0 We could just add another field, stl="1" say to the output of var-update, -var-list-children, etc. >... > For scripting purposes, and for simplicity in general, in better if one > has to implement just one function for any new type. Further, while mapping > from index to value is simple for std::vector, it's much less trivial for > list, and even less trivial for map. We better not traverse the list when > getting each element. > > So, I will prefer a mechanism where one can write a function taking a > varobj. That function should be able to compute the list of children, and > then create varobj children specifying the value directly. So, in case of > std::list, we'd traverse the list once, get the values and create varobjs > with those values. Of course, we'd need some support -- in particular a > version of create_child that takes a value. We will need to change > varobj_update so that it knows not to call value_of_child on children of > special varobj, as well. I think for lists, maps etc, Gdb needs to traverse the internal data structure each to see if there are new elements or if any have been deleted. This need only be done when execution stops, of course, but I guess it could be expensive for stepping. The ideas here are just for discussion and I'm more than happy to look at any changes you might like to make. -- Nick http://www.inet.net.nz/~nickrob