From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31597 invoked by alias); 17 Jan 2007 22:14:49 -0000 Received: (qmail 31575 invoked by uid 22791); 17 Jan 2007 22:14:48 -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; Wed, 17 Jan 2007 22:14:42 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H7J3C-0000MR-73 for gdb-patches@sources.redhat.com; Thu, 18 Jan 2007 01:14:39 +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 1H7J32-0000M9-BA; Thu, 18 Jan 2007 01:14:26 +0300 From: Vladimir Prus To: =?utf-8?q?Fr=C3=A9d=C3=A9ric_Riss?= Subject: Re: [RFC] Prints the frame id when target stops Date: Wed, 17 Jan 2007 22:14:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <45AB9A7F.1090502@st.com> <1169071153.5155.71.camel@funkylaptop> In-Reply-To: <1169071153.5155.71.camel@funkylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701180114.20338.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/msg00393.txt.bz2 On Thursday 18 January 2007 00:59, Fr=C3=A9d=C3=A9ric Riss wrote: > Le jeudi 18 janvier 2007 =C3=A0 00:37 +0300, Vladimir Prus a =C3=A9crit : > > >> 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. > > >=20 > > > Unforunately, making absolutely sure the stack did not change may not > > > be possible. > >=20 > > Are you sure? For example, if the only command since previous=20 > > -stack-list-frames was -exec-step, then the stack is the same. > >=20 > > For the cases where we're not sure, gdb can discard cached value > > and produce new. > >=20 > > 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. >=20 > 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? >=20 > 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. No, I don't have the slightest inclination to touch that. > 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. Or introduce 'struct cached_result_of_stack_list_frames' that can contain whatever I like and which can be conveniently edited. You've actually pointed a nice problem -- if frontend avoid -stack-list-fra= mes when frame id did not change, it will have stale address of the top frame t= oo. > 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. GDB always knows that it does a step. A frontend might be sending a command typed by the user, and that might be user-defined command, and there's no way to tell if there's step in that command. > 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. I think there are some simple optimizations we might make. - Volodya