From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30953 invoked by alias); 26 May 2007 02:29:34 -0000 Received: (qmail 30930 invoked by uid 22791); 26 May 2007 02:29:20 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 May 2007 02:29:18 +0000 Received: from kahikatea.snap.net.nz (194.60.255.123.dynamic.snap.net.nz [123.255.60.194]) by viper.snap.net.nz (Postfix) with ESMTP id 458A93D86ED; Sat, 26 May 2007 14:29:15 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 0F59C8F92C; Sat, 26 May 2007 14:29:09 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18007.39796.248187.540240@kahikatea.snap.net.nz> Date: Sat, 26 May 2007 02:29:00 -0000 To: Jim Blandy Cc: gdb@sourceware.org Subject: Re: Questions about MI variable objects In-Reply-To: References: <18006.22885.672223.12136@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.50.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00166.txt.bz2 > So, if Emacs wants displays to grey out when the frame disappears, > does it ever expect those expressions to become ungrey again? After > all, that frame is gone forever. Under what conditions should the > display become ungrey? If the frame_id matches again. > > > 4) If the user lets control run to 'foo' again, so the stack now looks > > > like: > > > > > > main -> bar (10) -> foo (9) > > > > > > what should happen to the display of 'x'? (I'd say it should show > > > '9'.) > > > > That's what Emacs currently does and what the default GDB behaviour gives, > > although Daniel J doesn't seem to think it's useful. > > Actually, I don't believe you. :) Would you humor me and try this > out? My mistake, I read too quickly. I was thinking it was going straight back into foo, having just come out. (I don't know why - ypu were quite clear.) > - Start with the program I posted. > - Set a breakpoint on foo. > - Run to the third hit (that is, foo (0)) > - Display 'x'. > - finish three times, so that we're back in main. We all agree the > display should be 'greyed' out at this point. > - continue to the next hit of foo. > > When I do this with what I assume are the corresponding MI commands, > the varobj I made for x in foo (0) is still out of scope. > > If I continue again, I happen to get a frame whose address matches the > original foo (0) address, and the varobj comes back in scope, but this > is, again, a spurious frame ID match. It happens only because the > frames sizes on the stack happen to line up. The compiler could > generate different, correct, code and the varobj behavior would stop > working. I have tried in the past to do something similar but could never get them to line up. (I tried to get two functions use the same amount of stack as one function.) > So, at the moment, your displays based on '*'-frame varobjs ungrey at > times that appear reasonable in simple test programs, but are actually > dependent on flukes of your compiler's stack management. > > Setting aside MI and GDB and varobjs, from your users' point of view, > when should that display come alive again? When the function and stack trace matches again. I generally use GDB in Emacs just to debug GDB and Emacs (yeah, I know, it's all a bit circular) and there the the frame_id only seems match again under these conditions However I can't really speak for others, as, currently, there aren't many people using GDB in Emacs 22. > > > If there's some general agreement on how these ought to behave (not > > > necessarily my guesses, just any agreement) then maybe we could make > > > MI varobjs match that behavior, so that each GUI variable display > > > could be backed by exactly one varobj, and GDB's reports on changes to > > > the varobj's state would correspond closely to changes in the GUI's > > > display. Varobjs exist to help GUIs, and GDB shouldn't be making GUIs > > > jump through hoops to get the behavior they want. > > > > I'm not sure how you intend to change GDB's behaviour but I think it should > > provide options rather than define the policy. > > MI is a protocol; I don't want to break backwards compatibility. But > there's no point in retaining backwards compatibility with a bug --- > when that bug's behavior is unpredictable. Well, you call it a fluke when it works, but I would call it an (unlucky) fluke when it fails. My view is unacceptable, of course, when delivering to customers. > > I don't really follow. Can you give an real example where frame IDs > > collide? > > Well, since it depends on the stack management code the compiler > emits, it's compiler-specific. But on a Fedora Core 6 x86 machine: Sure. Sorry, I should have followed through your first example. -- Nick http://www.inet.net.nz/~nickrob