From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30473 invoked by alias); 25 May 2007 03:35:12 -0000 Received: (qmail 30457 invoked by uid 22791); 25 May 2007 03:35:10 -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; Fri, 25 May 2007 03:35:07 +0000 Received: from kahikatea.snap.net.nz (220.61.255.123.dynamic.snap.net.nz [123.255.61.220]) by viper.snap.net.nz (Postfix) with ESMTP id CEA9E3DA8AA; Fri, 25 May 2007 15:35:03 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 56CCB8F92C; Fri, 25 May 2007 15:35:02 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18006.22885.672223.12136@kahikatea.snap.net.nz> Date: Fri, 25 May 2007 03:35:00 -0000 To: Jim Blandy Cc: gdb@sourceware.org Subject: Re: Questions about MI variable objects In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.50.1 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/msg00151.txt.bz2 > Suppose I'm stopped where the stack is like this: > > main -> foo (2) -> foo (1) -> foo (0) > > Suppose the top frame is selected, and the user adds a display for > 'x'. Clearly, it should show '0'. > > These are questions about what the GUI should display --- not what GDB > or MI or varobjs should do. They're about what you want the user to > see. > > 1) If the user selects the 'foo (1)' frame, what should happen to the > display of 'x'? Should it grey out? Should it now show 1? (I'd > say it should show 1.) I think "-var-create - @ var1" does this i.e. follows the selected frame but I currently only use "-var-create - * var1" to generate watch expressions for Emacs. I only grey expressions out when the frame they are created in disappears. > 2) If the user lets the 'foo (0)' call run to completion (as with a > GDB CLI 'finish' command), what should happen to the display of > 'x'? Should it disappear altogether? Should it grey out? Should > it show 1? (I'd say it should show 1.) There's a case for both behaviours. Emacs greys it out, but it could offer an option to show 1. This would only be an issue with recursion, and since iteration is generally better, I've not offered it for Emacs yet. > 3) If the user lets control go all the way back to main, what should > happen to the display? (I'd say it should grey out.) > > 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. > 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. > The principle behind my guesses is that a display should refer to a > particular variable in the source code --- a particular declaration > --- and should show its value whenever that declaration is in scope in > the selected frame. This is less specific than having the display > refer to a particular frame's instance of that variable, and more > specific than having it refer to any variable that happens to be in > scope under that name. But it's what I'd expect from a GUI. I don't know what to expect. I've always intended to base the display behavior on user feedback, but until Emacs is released I guess I won't get much. > At the moment, GDB tries to associate each varobj with a specific > function invocation. It's so easy to concoct a case where frame ID's > collide that in casual testing, the varobj code may appear to > implement something more like my suggested behavior. But it doesn't. I don't really follow. Can you give an real example where frame IDs collide? -- Nick http://www.inet.net.nz/~nickrob