From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12529 invoked by alias); 13 Apr 2006 17:07:49 -0000 Received: (qmail 12521 invoked by uid 22791); 13 Apr 2006 17:07:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 17:07:45 +0000 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k3DH7WhA013062; Thu, 13 Apr 2006 10:07:32 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id 2DF75324002; Thu, 13 Apr 2006 10:07:32 -0700 (PDT) In-Reply-To: References: <1A00C3C1-BDF5-489E-A36A-A1E5C20E102A@apple.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: -var-update and address changes Date: Thu, 13 Apr 2006 17:31:00 -0000 To: Vladimir Prus 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/msg00161.txt.bz2 On Apr 13, 2006, at 1:26 AM, Vladimir Prus wrote: > Jim Ingham wrote: > > >>> So, the only solution is to remove all varobjs, and create them >>> afresh, >>> which is contrary to the very purpose of varobjs. >>> >>> 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? >> >> That's what I would suggest. It seemed the simplest way to handle >> this when we were first thinking about it. > > FWIW, I've imp^H^H^Hkluged this by parsing the output of "info frame" > command. This gets me full frame id, but this should really be > inside MI. > >>> And I still don't know what to do about variable shadowing inside a >>> single >>> function. >> >> I added another option to -stack-list-locals to print all the blocks >> in a given function. Using this plus the option to have -stack-list- >> locals return variable object, you will get all the shadowed >> variables in the function as varobj's when you enter the function. >> Then the varobj system will tell you which of these are in and out of >> scope at any given PC. > > You mean, using -var-update and the "in_scope" attribute? Yes, -var-update will list as changed any varobj that has come into or out of scope since the last -var-update. > >> This all works in our branch if you want to see one example of how to >> do it. > > Unfortunately, last time I tried it did not build on Linux. Sorry 'bout that. We only ever build it on Mac OS X. Jim