From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10033 invoked by alias); 16 Jan 2007 21:12:55 -0000 Received: (qmail 10023 invoked by uid 22791); 16 Jan 2007 21:12:54 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Jan 2007 21:12:49 +0000 Received: from kahikatea.snap.net.nz (unknown [123.255.62.204]) by viper.snap.net.nz (Postfix) with ESMTP id 420E43D8EBD; Wed, 17 Jan 2007 10:12:42 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 2B75D4F6C7; Wed, 17 Jan 2007 10:12:40 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17837.16328.46414.146270@kahikatea.snap.net.nz> Date: Tue, 16 Jan 2007 21:12:00 -0000 To: Vladimir Prus Cc: Denis PILAT , gdb-patches@sources.redhat.com Subject: Re: [RFC] Prints the frame id when target stops In-Reply-To: References: <45AB9A7F.1090502@st.com> X-Mailer: VM 7.19 under Emacs 22.0.92.10 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: 2007-01/txt/msg00363.txt.bz2 > > 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. I started looking at the frame ID to detect when the stack changed in: http://sourceware.org/ml/gdb/2006-06/msg00162.html but Daniel J said: DJ> You can encounter the same frame ID for two consecutive stops DJ> but have a different backtrace, e.g. if you continued and then DJ> hit a breakpoint near the same function. More recently I looked at Apple's approach which seems to just add a hook in select_frame: http://sourceware.org/ml/gdb-patches/2007-01/msg00037.html -- Nick http://www.inet.net.nz/~nickrob