From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17525 invoked by alias); 11 Sep 2009 19:41:02 -0000 Received: (qmail 17505 invoked by uid 22791); 11 Sep 2009 19:41:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Sep 2009 19:40:54 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8BJebRg001080; Fri, 11 Sep 2009 15:40:39 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8BJePFx001073; Fri, 11 Sep 2009 15:40:35 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n8BJeNBG032577; Fri, 11 Sep 2009 15:40:24 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8B5C4378188; Fri, 11 Sep 2009 13:40:23 -0600 (MDT) From: Tom Tromey To: nickrob@snap.net.nz (Nick Roberts) Cc: gdb-patches@sourceware.org Subject: Re: Patch: implement new dynamic varobj spec References: <19113.58116.381538.294631@totara.tehura.co.nz> Reply-To: Tom Tromey Date: Fri, 11 Sep 2009 19:41:00 -0000 In-Reply-To: <19113.58116.381538.294631@totara.tehura.co.nz> (Nick Roberts's message of "Fri, 11 Sep 2009 17:41:24 +1200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00330.txt.bz2 >>>>> "Nick" == Nick Roberts writes: Nick> Dynamic variable objects seem to behave differently to the current Nick> ones: Yeah. Nick> 1) Children are reported (and presumably created) in var-update Nick> even though only a root variable object may have been created, Nick> i.e., not -var-list-children has been invoked. It should only report children if you previously requested them. It may create a child at any time by asking the Python printer; but a child created this way won't be reported. This is needed to properly report has_more. Nick> 2) -var-update seems to list changes to children of dynamic Nick> objects in reverse numerical order. Oh, odd. But not a bug, really, as the order is not specified. Nick> Does -var-set-update-range only work for dynamic variable objects Nick> - the documentation doesn't say but I couldn't get it to work with Nick> current ones. Yeah, I think it ought to work. I'm not sure how useful it is, though. Nick> With dynamic variable objects I could restrict the Nick> range but it didn't seem to match up (from seem to be ignored). I will look into this. Nick> The new FROM TO arguments for -var-list-children work with current Nick> variable objects but it seems that GDB just restricts what it Nick> prints but stores the whole vector which doesn't seem to save Nick> memory. Would it not be better to create children in the range Nick> specified since the array might be large and the front end only Nick> needs the values it displays. We designed a very simple Python API that does not support random access. The reason for this is that a simple API is easier for users. Naturally, this is an arguable decision. The real intent for limiting the range is not to save memory but to avoid problems printing uninitialized containers. I think a front end ought to always restrict the range when fetching the children of a dynamic varobj. I suppose I will update the documentation to say this. For dynamic varobjs, we do save a bit of memory because the TO argument limits how many children we compute. Nick> Likewise with -var-set-update-range: does GDB track all changes Nick> and just report a restricted set, or restrict what it tracks? It always starts over at 0, and then filters on the low side after computing differences. On the high side, TO (really TO+1, due to has_more computation) limits how many children we fetch. Nick> I have a few thoughts about the documentation: Thanks, I'll fix these. Nick> The field `displayhint' seems very useful with -var-create but Nick> does it serve any purpose when output with -var-update? It could change -- bizarre but in theory possible. Nick> The field `has_more' seems to be overloaded depending on whether Nick> its output from -var-create, -var-list-children or -var-update. How do you mean? I think it means pretty much the same thing in all cases: it is true if the object has children beyond what you've requested. Nick> Existing documentation uses @var for field names, while new uses @samp. Yeah. @var seems clearly wrong there. I will change the new code though. Nick> I find varobj.c hard to read Yes, me too. Tom