From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3730 invoked by alias); 22 Nov 2013 16:37:54 -0000 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 Received: (qmail 3721 invoked by uid 89); 22 Nov 2013 16:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Nov 2013 16:37:53 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAMGbiGw029743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Nov 2013 11:37:44 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAMGbgRD014076; Fri, 22 Nov 2013 11:37:43 -0500 Message-ID: <528F8856.9030606@redhat.com> Date: Fri, 22 Nov 2013 16:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey CC: Yao Qi , "gdb@sourceware.org" Subject: Re: semantics of dynamic varobj References: <528F5839.4050100@codesourcery.com> <87eh68e7qk.fsf@fleche.redhat.com> In-Reply-To: <87eh68e7qk.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00088.txt.bz2 On 11/22/2013 04:12 PM, Tom Tromey wrote: > Second, dynamic varobjs have different semantics than ordinary ones, so > they are only enabled when the client requests them. (And, clients may > use the "python" feature to decide this, since that's the only signal > right now that they exist.) I no longer have the full context, but these varobjs are also only enabled when the client requests them (a new option to -var-create, IIRC). That is, a regular varobj will include both unavailable and available fields, with unavailable fields listed as "value=". For those, which fields are listed can be determined "statically", as usual, from the debug info. While this new varobj lists only the available fields, skipping the unavailable ones. I recall doing this on top of regular varobjs first, and then realizing they behave just like dynamic varobjs, because we have no random access to the children, and we also want to let the frontend know the number of children changed when we move between trace frames, with -var-update, and ynamic varobjs also support that. In reality, I think we would be able to implement these new varobjs as real dynamic python varobjs, with some sort of pretty printer that skips these unavailable fields, though we might need some fixes to the dynamic varobj code that were done as part of this work (also useful for python varobjs, IIRC), and also I don't think python is aware of unavailable values yet either. That said, I do prefer a native implementation. (*) - Yao, as usual, the whole rationale for that should be in CS's internal archives. -- Pedro Alves