From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30498 invoked by alias); 12 Jul 2002 18:30:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30490 invoked from network); 12 Jul 2002 18:30:50 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 12 Jul 2002 18:30:50 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g6CIUoA15845 for ; Fri, 12 Jul 2002 11:30:50 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 12 Jul 2002 11:30:48 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g6CIUmT25441 for ; Fri, 12 Jul 2002 11:30:48 -0700 (PDT) Date: Fri, 12 Jul 2002 11:30:00 -0000 Subject: Re: Problem with MI -var-evaluate-expression command Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v533) From: Jim Ingham To: Content-Transfer-Encoding: 7bit In-Reply-To: <1026487389.32493.ezmlm@sources.redhat.com> Message-Id: <7D03A260-95C5-11D6-AB35-00039379E320@> X-SW-Source: 2002-07/txt/msg00137.txt.bz2 Mo, On Friday, July 12, 2002, at 08:23 AM, gdb-digest-help@sources.redhat.com wrote: > From: Mo DeJong > Date: Thu Jul 11, 2002 12:18:39 PM US/Pacific > To: gdb@sources.redhat.com > Subject: Re: Problem with MI -var-evaluate-expression command > > > On Wed, 10 Jul 2002 17:31:11 -0700 (PDT) > Keith Seitz wrote: > >> How is a UI to know what the children of svar are? You do, because >> you're >> a human, but a UI reacting programmatically could not automatically >> know >> that svar has a child named "v1" _until_ it asks svar for its children >> (thus creating the varobjs). > > ... > >> Now, when the user hits the "+", Insight will ask the varobj for its >> children. It gets back a list of varobjs. It then repeats steps 2-5 >> for >> each of these new varobjs. > > It sounds like that works just fine for a watch window where each > child will be displayed. I just wonder if that is the only valid use > case. > I am looking at building a scripting interface to the gdb/mi, so I > don't need > watch window semantics just now. > > My reading of the docs seems to indicate that the variable objects > interface is an improvement over just evaluating plain expressions > since the same "syntax" would be used to access C, C++, or Java > objects with children. I also liked the fact that you could set the > format of the returned value and then pass the whole "var object" > around from one function to another. That said, this > -var-evaluate-expression > children thing has got me thinking that I should just stick with > -data-evaluate-expression and skip the -var-* methods. Here is why. > > One can evaluate an expression like so quite easily: > > -data-evaluate-expression "objPtr->member1->dataPtr->bytes" > > But to do this same thing with a variable object I would need to > send these commands. > > -var-create objPtr * "objPtr" > -var-list-children objPtr > -var-list-children objPtr.member1 > -var-list-children objPtr.member1.dataPtr > -var-evaluate-expression objPtr.member1.dataPtr.bytes > > Now, I could keep my own record of the variables that "know" what > their children are and check this record every time a variable is > accessed from my API. But, that just strikes me as really ugly and > it seems to waste a lot of bandwidth. I don't have a problem with > leaving support for the -var-* methods out of my wrapper > because of this issue, I just thought I would bring it up. > > In any event, the docs for the -var-evaluate-expression should be > updated to explicitly state that the user needs to call > -var-list-children > for a variable object before accessing any children. One thing here. The fact that the name of the children is parent.child is an implementation detail, not a public interface. For instance, in C++ classes, the name of the public instance variable foo of object objPtr is objPtr.public.foo. I don't really think it is a good idea to change this, because as some point I would kind of like to shorten these, they get really cumbersome for deep trees... So assuming that you know the varobj name of member1 of objPtr is objPtr.member1 isn't really safe. Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer