From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20156 invoked by alias); 2 Aug 2002 13:28:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20147 invoked from network); 2 Aug 2002 13:27:59 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 2 Aug 2002 13:27:59 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id E9114108C9; Fri, 2 Aug 2002 09:26:15 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15690.34935.728157.10746@localhost.redhat.com> Date: Fri, 02 Aug 2002 06:28:00 -0000 To: Mo DeJong Cc: gdb@sources.redhat.com Subject: Re: Proposed mod for stack-select-frame MI command In-Reply-To: <20020801191811.4144cc0c.supermo@bayarea.net> References: <20020725202141.34b12c04.supermo@bayarea.net> <3D49C36A.9060504@ges.redhat.com> <20020801191811.4144cc0c.supermo@bayarea.net> X-SW-Source: 2002-08/txt/msg00011.txt.bz2 Mo DeJong writes: > On Thu, 01 Aug 2002 19:25:30 -0400 > Andrew Cagney wrote: > > > Mo, is this needed or is it just a convenience? Won't the client need > > to track the current stack level and hence can simply adjust/use that > > local copy. > > I am not sure what the possible complications of that approach might > be. You could assume that the stack level was reset to 0 when a > breakpoint was hit and then increment and decrement it. I am > not sure what would happen if you started calling inferior functions > though. I have seen gdb do things like switch back to the innermost > frame after calling an inferior function at some other level of the > stack. If that happened, the client would think the stack was one > value while gdb could think it was another. I would rather just > keep all that info in gdb. The gui needs to know the current selected frame, in order to update the windows. If such information is only in gdb wouldn't you end up making more queries to gdb (one for window/object that needs updating)? In theory whenever the level changes, the gui should be notified. The fact that this does not happen at the moment, because there is no notification event that gets triggered when the current frame changes is a deficiency of the MI mechanism, and should be fixed. (I guess a merge from the MI branch would solve this). > > You would also need to assume that the client would not use the > frame, up, down and other cli methods via the MI. If they did, the > local stack level integer that the client held would be wrong. Yes, this is the real bug. If this gets fixed, the need for up/down functionality becomes less compelling. > > This just seems like something that should be easy to do via the > MI. It is just a way to access up or down like functionality. > If you check the existing docs for the -stack-select-frame, it > states that up, down, up-silent, and down-silent commands > map the -stack-select-frame. My take on the change is that it > gets the implementation in line with the documentation. > So to sum up, I think it is needed. > The 'equivalence' is meant to be a loose one. It just means that you can achieve the same functionality using a combination of -stack-select-frame and other commands. I.e. you can do something like: -stack-select-frame (current_frame_level - 1) -stack-select-frame (current_frame_level + 1) where current_frame_level is obtained from a previous -stack-info-frame, for instance. The underlying assumption was that the GUI should know at all times the current frame level. Elena > cheers > Mo