From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3679 invoked by alias); 13 Apr 2006 08:26:57 -0000 Received: (qmail 3671 invoked by uid 22791); 13 Apr 2006 08:26:57 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 08:26:54 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FTxAB-0007hi-HU for gdb@sources.redhat.com; Thu, 13 Apr 2006 10:26:51 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Apr 2006 10:26:51 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Apr 2006 10:26:51 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: -var-update and address changes Date: Thu, 13 Apr 2006 09:25:00 -0000 Message-ID: References: <1A00C3C1-BDF5-489E-A36A-A1E5C20E102A@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00155.txt.bz2 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? > 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. - Volodya