From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21342 invoked by alias); 2 Aug 2002 02:18:04 -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 21334 invoked from network); 2 Aug 2002 02:18:03 -0000 Received: from unknown (HELO mta6.snfc21.pbi.net) (206.13.28.240) by sources.redhat.com with SMTP; 2 Aug 2002 02:18:03 -0000 Received: from modrick ([66.120.11.181]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H07009PP2E3J9@mta6.snfc21.pbi.net> for gdb@sources.redhat.com; Thu, 01 Aug 2002 19:18:03 -0700 (PDT) Date: Thu, 01 Aug 2002 19:18:00 -0000 From: Mo DeJong Subject: Re: Proposed mod for stack-select-frame MI command In-reply-to: <3D49C36A.9060504@ges.redhat.com> To: gdb@sources.redhat.com Message-id: <20020801191811.4144cc0c.supermo@bayarea.net> Organization: House of Mirth MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20020725202141.34b12c04.supermo@bayarea.net> <3D49C36A.9060504@ges.redhat.com> X-SW-Source: 2002-08/txt/msg00007.txt.bz2 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. 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. 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. cheers Mo