From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20283 invoked by alias); 16 Sep 2009 09:56:22 -0000 Received: (qmail 20274 invoked by uid 22791); 16 Sep 2009 09:56:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 09:56:18 +0000 Received: from totara (34.60.255.123.dynamic.snap.net.nz [123.255.60.34]) by viper.snap.net.nz (Postfix) with ESMTP id 5858F3DA40A; Wed, 16 Sep 2009 21:56:11 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 65C38C164; Wed, 16 Sep 2009 21:56:09 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19120.46647.453792.806115@totara.tehura.co.nz> Date: Wed, 16 Sep 2009 09:56:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: Patch: implement new dynamic varobj spec In-Reply-To: References: <19120.5383.874148.235514@totara.tehura.co.nz> From: nickrob@snap.net.nz (Nick Roberts) 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: 2009-09/txt/msg00505.txt.bz2 > > the additional children appear. With a string there are never any > > children so you would not want an expandable node. AFAICS the only way > > the front end can discriminate is through the displayhint field. > > Right, so for string you'll have numchildren=0, has_more=0, and no need to > make anything expandable. For vector that is initially empty, you'll have > the same, so it won't be expandable, but if things are pushed, -var-update > will report has_more=1. You can detect that, and make the item expandable > at this point. OK. In that case I misunderstood the meaning of the has_more field. I had assumed it was just non-zero when -var-set-update-range was restricted. The documentation states that -var-update returns the list of variable objects whose values have changed. More precisely: Here, "changed" means that the result of `-var-evaluate-expression' before and after the `-var-update' is different. That appears to no longer be true and its definition needs to be generalised for dynamic variable objects. Actually I wonder if it might be a good idea to split the node on variable objects and describe normal (static?) variable objects and dynamic ones separately. It has become very long and that way the user won't be overwhelmed by too much information at first reading. -- Nick http://www.inet.net.nz/~nickrob