From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26184 invoked by alias); 18 Jan 2007 07:58:19 -0000 Received: (qmail 26165 invoked by uid 22791); 18 Jan 2007 07:58:18 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Jan 2007 07:58:09 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-02.spheriq.net with ESMTP id l0I7w7Qq007696 for ; Thu, 18 Jan 2007 07:58:07 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-03.spheriq.net with ESMTP id l0I7w0mR030652 for ; Thu, 18 Jan 2007 07:58:05 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id l0I7vvRX006206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 18 Jan 2007 07:58:00 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 88330DA42; Thu, 18 Jan 2007 07:57:43 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1C3EE47259; Thu, 18 Jan 2007 07:57:43 +0000 (GMT) Received: from [10.18.180.51] (crx3051.cro.st.com [10.18.180.51]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CJL25544 (AUTH "frederic riss"); Thu, 18 Jan 2007 08:57:41 +0100 (CET) Subject: Re: [RFC] Prints the frame id when target stops From: Frederic RISS To: Daniel Jacobowitz Cc: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss , Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: <20070117221742.GA15116@nevyn.them.org> 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> <1169071153.5155.71.camel@funkylaptop> <20070117221742.GA15116@nevyn.them.org> Content-Type: text/plain; charset=UTF-8 Date: Thu, 18 Jan 2007 07:58:00 -0000 Message-Id: <1169107060.3288.126.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 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/msg00396.txt.bz2 On Wed, 2007-01-17 at 17:17 -0500, Daniel Jacobowitz wrote: > On Wed, Jan 17, 2007 at 10:59:13PM +0100, Frédéric Riss wrote: > > 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? > > How much do we know about why it takes a long time? Very good question :-) In Denis' case, he's using a JTAG link driven by a probe which is in turn connected through ethernet to the workstation where GDB is running. I'm quite sure that the latencies at each memory access are what's taking time, because the unwinding doesn't require any complex handling other than retrieving the saved frame pointer (and there's no prolog analysis going on). IIRC, -stack-list-frames was taking an average of half a second to complete. > For instance: > - We can speed up the psymtab lookup which currently shows up in > profiles. A coworker of mine gave me some clever ideas on how > to do this if anyone wants to try it :-) Hehe. What's the idea? maybe someone will pick it up. > - We can speed up prologue analyzers by judicious use of caching, > in a way that's completely reliable. DWARF2 CFI is already pretty > speedy. > > If these sorts of things are enough to help... > > > 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. > > I suspect you can only do this in stepi, really - step/next can end up > in strange places... ... and end up in a frame with the same frame id? Seems unlikely, but then GDB isn't the place where you'd want to trade accuracy for a very small speedup. Fred.