From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16541 invoked by alias); 6 Apr 2006 16:49:38 -0000 Received: (qmail 16532 invoked by uid 22791); 6 Apr 2006 16:49:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 16:49:33 +0000 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k36GmpNM023295; Thu, 6 Apr 2006 09:48:51 -0700 (PDT) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay6.apple.com (Apple SCV relay) with ESMTP id 8B33F7A; Thu, 6 Apr 2006 09:48:51 -0700 (PDT) In-Reply-To: <20060406144131.GA26938@nevyn.them.org> References: <200602171724.03824.ghost@cs.msu.su> <200604061745.16585.ghost@cs.msu.su> <20060406140126.GA26035@nevyn.them.org> <200604061831.24650.ghost@cs.msu.su> <20060406144131.GA26938@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vladimir Prus , GDB List Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Thu, 06 Apr 2006 18:53:00 -0000 To: Daniel Jacobowitz X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00074.txt.bz2 On Apr 6, 2006, at 7:41 AM, Daniel Jacobowitz wrote: > On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus wrote: >>>> There's no indication that 'TMP' varobj belongs to the stack >>>> frame we've >>>> already left. This is with vanilla 6.4. >>> >>> Interesting, the check isn't on this path. I wonder if we really >>> need >>> both different ways to get at the value of a variable. >>> varobj_update >>> uses value_of_root, but -var-evaluate-expression uses >>> value_of_variable. I bet we have some redundant code here. >>> Maybe not, >>> value_of_variable is only used for strings, the others work on >>> struct >>> value. >> >> I don't quite understand if you're saying that the current >> behaviour is a bug, >> or not. Can you clarify? > > I don't know. It's an interface. > > Maybe it is an error for you to try to evaluate something after > -var-update says it has gone out of scope. > > Maybe -var-evaluate-expression should report not in scope. > > Someone with more MI experience would have to decide. I don't know why it was originally done this way. But in practice it doesn't much matter. The separation between "update" and "evaluate" is useful, since "what's changed" and "give me a value" are questions you want to ask separately. Since the UI generally knows what it wants to fetch, having -var-evaluate-expression error if the varobj was out of scope hasn't been a big deal in practice. > >> Yes, this is indeed what I'm after. However, now there's reverse >> problem. Say >> I create variable object for variable 'i'. Then during stepping I >> enter >> function that also has variable 'i'. I need to detect, somehow, >> that 'i' >> varobj created earlier relates to the parent stack frame, not the >> current, >> and that I have to create new variable object. >> >> How do I do that? Using -var-update does not seem to produce this >> information? >> Am I supposed to manually keep track of frame-id where variable >> object was >> created? And if so, how do I get frame-id? > > I don't know. Maybe Jim will comment. One of the changes that I made early on when we started using the MI seriously for Xcode was to add an option to -stack-list-locals and - stack-list-args to make varobj's for all the locals/args. We always use these commands to get the varobj's that correspond to the stack frame. Then it is a simple matter in the UI to tie these variable objects to their frames, and update, evaluate, whatever, them as appropriate for the frame the user is currently looking at. I think it's a lot easier doing it this way than having an option in the MI to report the varobj's frame, and then having to check that against the stack each time. The other bit involved here is that Xcode does keep track of the last stack and compares it against the current stack every time you stop. That way it knows which frames it does or doesn't have to create new variable objects for. Jim > > -- > Daniel Jacobowitz > CodeSourcery