From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11854 invoked by alias); 17 Jan 2007 21:59:27 -0000 Received: (qmail 11819 invoked by uid 22791); 17 Jan 2007 21:59:26 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.172) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Jan 2007 21:59:19 +0000 Received: by ug-out-1314.google.com with SMTP id 39so2681ugf for ; Wed, 17 Jan 2007 13:59:16 -0800 (PST) Received: by 10.66.242.20 with SMTP id p20mr74447ugh.1169071156246; Wed, 17 Jan 2007 13:59:16 -0800 (PST) Received: from ?192.168.0.11? ( [82.229.199.15]) by mx.google.com with ESMTP id 39sm9129593ugb.2007.01.17.13.59.15; Wed, 17 Jan 2007 13:59:15 -0800 (PST) Subject: Re: [RFC] Prints the frame id when target stops From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss To: Vladimir Prus Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <45AB9A7F.1090502@st.com> <17837.16328.46414.146270@kahikatea.snap.net.nz> <200701170234.34303.ghost@cs.msu.su> <200701172128.l0HLSOTc024176@brahms.sibelius.xs4all.nl> Content-Type: text/plain; charset=UTF-8 Date: Wed, 17 Jan 2007 21:59:00 -0000 Message-Id: <1169071153.5155.71.camel@funkylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit 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/msg00392.txt.bz2 Le jeudi 18 janvier 2007 à 00:37 +0300, Vladimir Prus a écrit : > >> 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. > > > > Unforunately, making absolutely sure the stack did not change may not > > be possible. > > Are you sure? For example, if the only command since previous > -stack-list-frames was -exec-step, then the stack is the same. > > For the cases where we're not sure, gdb can discard cached value > and produce new. > > The thing is, if the frontend tries to compare old frame id to > new frame id, and skip -stack-list-frames if they are equal, > it's not going to be any more reliable than doing similar check > in gdb. And in gdb, we can have better checks. Have you an idea how you would like the caching to work? Do you mean not discarding the frame cache, or caching the returned string? If you want the first approach (keep the frame cache), then this is quite an intrusive change. It would also require keeping a frame cache per-thread and not as a global like it's done now. If you just want to cache the result of -stack-list-frames, then you'd have to edit out the addr field which contains the frame's PC for the top frame... not very nice. Also, I don't see how we could have better checks within GDB than within the frontend. The only reliable check is IMHO to compare frame ids after steps and nexts. Any other execution control command requires to re-unwind the whole stack. This check seems to be as reliable in the frontend as in GDB. I agree with your point though: making -stack-list-frames as fast as possible would benefit all frontends. However, it seems hard to modify GDB's frame handling to handle that correctly. Fred.