From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5499 invoked by alias); 3 Jan 2012 17:11:09 -0000 Received: (qmail 5487 invoked by uid 22791); 3 Jan 2012 17:11:06 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Jan 2012 17:10:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 020B02BAE5C; Tue, 3 Jan 2012 12:10:52 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6QLlWUMFLMop; Tue, 3 Jan 2012 12:10:51 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5F34C2BADCB; Tue, 3 Jan 2012 12:10:51 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id D97E8145615; Tue, 3 Jan 2012 21:10:40 +0400 (RET) Date: Tue, 03 Jan 2012 17:11:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org, vladimir@codesourcery.com Subject: Re: RFC: how to handle mutable types in varobj? Message-ID: <20120103171040.GO2730@adacore.com> References: <20111228155943.GD2632@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2012-01/txt/msg00099.txt.bz2 > Pedro> So, I factored out the "listing dynamic varobj's > Pedro> children" code behind a common interface, making use of a new > Pedro> iterator "virtual" object (struct varobj_iter), and reimplemented > Pedro> both pretty-printing varobjs and available-children-only varobjs using > Pedro> that same interface. > > Sounds nice. I haven't had time to look at this lately. But it does sound nice. On the other hand, Pedro's answers gave me an idea that sounds obvious in retrospect. I tested how floating varobjs work in C: I have two struct types, where the first couple of fields have the same name and type. The last two change from one location to the next. At the first location, I did: | -var-create v @ v | ^done,name="v",numchild="4",value="{...}",type="struct variant_1",thread-id="1",has_more="0" | (gdb) | -var-list-children 1 v | ^done,numchild="4",children=[child={name="v.disc",exp="disc",numchild="0",value="1",type="int",thread-id="1"},child={name="v.a",exp="a",numchild="0",value="2",type="int",thread-id="1"},child={name="v.b",exp="b",numchild="0",value="3",type="int",thread-id="1"},child={name="v.c",exp="c",numchild="0",value="5",type="int",thread-id="1"}],has_more="0" And then resumed the execution until reaching the second location, where a -var-update * yields: | -var-update 1 v | ^done,changelist=[{name="v",value="{...}",in_scope="true",type_changed="true",new_type="struct variant_2",new_num_children="4",has_more="0"}] As you can see, all children of v have disappeared. So, as long as the front-end does not make the extra assumption that type-changes only occur with floating varobjs, a first step at implementing mutations could be done that way. In the light of this, do you guys think that a patch along the lines of what I sent would be acceptable? http://www.sourceware.org/ml/gdb-patches/2011-12/msg00886.html The gist of the change is a language-specific hook, and a couple of blobs (one for root value, one for children values) that test for mutation, and destroy children if detected. As a second phase, we could try designing a little better how dynamic objects behave. But I'd rather do something simple first, familiarize myself with that, and then move on to a more difficult project. > I think the only caveat is that it has to be requested. Another element that makes me think it's better to start simple first. > But, presumably Joel has a particular client in mind. It's an Eclipse client. I'm not very familiar with any of them, so I don't know how many instantiations of that project there are out there. I will check with the other engineer at AdaCore who looks at this side of things, to see how he would react to non-floating varobjs that mutate... Cheers, -- Joel