From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1512 invoked by alias); 14 Apr 2006 19:48:25 -0000 Received: (qmail 1503 invoked by uid 22791); 14 Apr 2006 19:48:25 -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; Fri, 14 Apr 2006 19:48:23 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k3EJlWm0017968; Fri, 14 Apr 2006 12:47:32 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id 3AE8C324013; Fri, 14 Apr 2006 12:47:30 -0700 (PDT) In-Reply-To: <20060414131549.GC12955@nevyn.them.org> References: <1A00C3C1-BDF5-489E-A36A-A1E5C20E102A@apple.com> <20060414131549.GC12955@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@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: -var-update and address changes Date: Fri, 14 Apr 2006 20:03:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.749.3) 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/msg00208.txt.bz2 On Apr 14, 2006, at 6:15 AM, Daniel Jacobowitz wrote: > On Wed, Apr 12, 2006 at 04:04:36PM +0400, Vladimir Prus wrote: >> I'm running into what looks like a bug in -var-update. Basically, >> I create a >> varobj with "&variable", then I enter a function that has a >> variable with >> the same name, and -var-update does not report anything. > > I think we've concluded that this is a feature, not a bug... > >> The value of "&i" changes, but -var-update does not report this. >> This can be >> explained by the fact that varobjs are "bound" to the stack frame >> where >> they were created, but that "binding" is not mentioned in >> documentation. > > ... and adding this to the manual would be welcome. The docs are there, just not altogether clear. They say: The frame under which the expression should be evaluated can be specified by @var{frame-addr}. A @samp{*} indicates that the current frame should be used. The last sentence means that the varobj will be bound to whatever the current frame is. It can be read to mean "it's re-evaluated in whatever the current frame happens to be when you update it" - maybe that's how Vlad understood it. So you just need to make this a little clearer. Note as an aside, that we had to add another varobj type which is evaluated in the selected frame, whatever that happens to be. That was useful for a general "variable inspector" window. People wanted to put some expression there, and have it re-evaluated in the topmost frame whenever they stopped. So we added that functionality. But that is clearly distinct from what the "*" varobj type is supposed to mean. > >> The problem I'm trying to solve is this: >> 1. In some frame, I create varobj for 'i'. >> 2. After continue, I see that there's local variable 'i', and I >> want to find >> out if previously-created varobj can be used to show this local >> 'i', or if >> I should create new 'i'. > > OK, so, you need to map this to a frame. Apple outputs the frame > address. I think this is pretty nasty; frame IDs ought to be > opaque in > the interface (e.g. in case we change their contents again)... Jim, > what does your front end do with the frame IDs? Is there anything > besides testing for equality? If there is, we can use unique opaque > identifiers instead; personally I'm much happier with that. The > best unique identifier might in fact be the contents of the frame > ID; I'm just trying to define how clients are allowed to interpret > it, hopefully not at all. The fp part is just used as part of the frame fingerprint. The pc is used for other purposes of course (for instance if the disassembly window is open), but the fp part is just used to check whether the frame needs to be refreshed. I have no problem with it being opaque. > >> Can somebody suggest the right fix? So far, I think that the simplest >> approach is to make gdb print stack address of current frame, like >> is done >> on the Apple branch: >> >> 553^done,stack=[frame= >> {level="0",addr="0x00003db0",fp="0xbffff2c0",...... >> >> That way, frontend can deal with the issue of frame stacks >> themself, and >> -var-update will be only used when single-stepping inside a given >> frame. >> Will patches to implement this be welcome? > > I guess. It seems reasonable. > > The MI working group list is now open; should we move this sort of > conversation there? That seems appropriate. Jim