From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32514 invoked by alias); 25 Jul 2002 23:38:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32507 invoked from network); 25 Jul 2002 23:38:01 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 25 Jul 2002 23:38:01 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2E12F3EBA; Thu, 25 Jul 2002 19:38:01 -0400 (EDT) Message-ID: <3D408BD9.90403@ges.redhat.com> Date: Thu, 25 Jul 2002 17:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020708 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mo DeJong Cc: gdb-patches@sources.redhat.com Subject: Re: [Patch] add implementation of stack-info-frame MI command References: <20020725143758.3cbf44d1.supermo@bayarea.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00524.txt.bz2 See my post to GDB@. I think this should be handled as an event and not as a command. The user entering a command like ``up'' needs to trigger the event notification anyway. enjoy, Andrew > While using the MI, I noticed that there is a real problem trying to find > the current stack level. One could get the stack and look at the level > value of the first frame or parse the results of a cli frame command, > but these both seem ugly. What is needed is a stack-info-frame that > returns the current stack level to complement the stack-select-frame > which selects a stack level. > > Here is what I propose: > > -stack-info-frame > ^done,level="0" > (gdb) > -stack-select-frame 5 > ^done > (gdb) > -stack-info-frame > ^done,level="5" > (gdb) > > The stack-info-frame command is currently unimplemented > even though it appears in the documentation, so there is > no way this patch could break anything. The only objection > I could think of was that folks might want the command > to return all the info about the current frame, like the > stack-list-frames method. That is actually not needed since > one could always run stack-list-frames and then select > a stack level out of the returned frames. In real code, > it is better to query the whole stack as opposed to changing > the stack, doing a query of the current frame, changing the > stack, then doing a query, and so on. > > I forgot to mention in my last patch that I sent in my FSF > copyright paperwork, so that should not stand in the way > of incorporating my patches any longer. > > cheers > Mo