From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6836 invoked by alias); 16 Jan 2007 23:38:46 -0000 Received: (qmail 6810 invoked by uid 22791); 16 Jan 2007 23:38:45 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Jan 2007 23:38:38 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H6xss-00073g-EK for gdb-patches@sources.redhat.com; Wed, 17 Jan 2007 02:38:35 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1H6xp8-0006yq-RW; Wed, 17 Jan 2007 02:34:39 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [RFC] Prints the frame id when target stops Date: Tue, 16 Jan 2007 23:38:00 -0000 User-Agent: KMail/1.9.1 Cc: Denis PILAT , gdb-patches@sources.redhat.com References: <45AB9A7F.1090502@st.com> <17837.16328.46414.146270@kahikatea.snap.net.nz> In-Reply-To: <17837.16328.46414.146270@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701170234.34303.ghost@cs.msu.su> 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: 2007-01/txt/msg00374.txt.bz2 On Wednesday 17 January 2007 00:12, Nick Roberts wrote: > > > We'd like to avoid refreshing the thread and the frame view when the user > > > perform a step (or a next) and when the program stops in the same thread > > > and in the same frame. In the stop reason we got the current thread id, > > > but we are missing something to identify the frame. That patch lets gdb > > > emits on the MI output a string that could be used to easily identify the > > > current frame. If you are ok with this approach then I'll update the > > > testsuite. > > > > Would not a better approach be to modify -stack-list-frames and friends, > > so that they check frame id internally, and it has not changed, just > > return the same result? Such approach will uniformly help all frontends, > > and won't expose new concepts in the interface. > > It would change the behviour of those commands but I guess it could be added > as an option. It actually won't. If -stack-list-frames is changed to return cached result when it's absolutely clear that the stack did not change, you have no behaviour change, just better performance. - Volodya