From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19556 invoked by alias); 23 Apr 2008 22:18:45 -0000 Received: (qmail 19547 invoked by uid 22791); 23 Apr 2008 22:18:45 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 22:18:18 +0000 Received: from kahikatea.snap.net.nz (190.30.255.123.static.snap.net.nz [123.255.30.190]) by viper.snap.net.nz (Postfix) with ESMTP id 015B73DA0FE; Thu, 24 Apr 2008 10:18:15 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 3D9468FC6D; Thu, 24 Apr 2008 10:01:22 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18447.45489.330759.603491@kahikatea.snap.net.nz> Date: Wed, 23 Apr 2008 23:23:00 -0000 To: Vladimir Prus Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames In-Reply-To: <200804231703.25325.vladimir@codesourcery.com> References: <18446.45778.889114.789630@kahikatea.snap.net.nz> <200804231349.35190.vladimir@codesourcery.com> <18447.12269.389044.431822@kahikatea.snap.net.nz> <200804231703.25325.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00538.txt.bz2 > > > Does that window shows: > > > > > > 1. Value of variable named XXX in the frame where that variable was > > > added to the window? > > > 2. Value of variable named XXX in the current frame > > > 3. Something else? > > > > It doesn't really matter how it was created. > > Of course it does, because for 2 (which are those floating varobjs), the > concept of frame varobj belongs is fairly moot. Floating varobjs are evaluated in the selected frame and that's the (changing) frame to which it belongs. > > > Well, for other frames I know what they are used for. > > > > (by frames you mean fields?) > > Yes. > > > Really? In the output of -stack-list-frames what are the pc address field > > for the outer frames used for? > > It's there so that you can know where you function is called from, in case > the caller is assembler and there's no other information about location. I mean it's not interesting to see the pc addresses for all the frames in the call stack simultaneously. Only the pc address of the selected frame is really of interest. >... > Yes, stack surely grows in the other directions on other architectures. But > that's probably not the main issue. What is the case when a user wants to > know which frame a variable having address XXX belongs to? If that variable > is varobj, GUI probably already recorded the association between varobj and > frame and is in position to show that directly. Gdb knows with which frame the varobj is associated but two frames might have the same variable name, and with recursion they might have the same procedure name. Then the user could only work out which was which (if he forgets when they were created) by comparing the frame addresses with the memory locations of the variable. -- Nick http://www.inet.net.nz/~nickrob