From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16298 invoked by alias); 24 Jul 2007 18:19:39 -0000 Received: (qmail 16290 invoked by uid 22791); 24 Jul 2007 18:19:38 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jul 2007 18:19:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CB4A5982CF; Tue, 24 Jul 2007 18:19:35 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 7F559982BA; Tue, 24 Jul 2007 18:19:35 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IDOyr-0004wD-EI; Tue, 24 Jul 2007 14:19:33 -0400 Date: Tue, 24 Jul 2007 18:22:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: gdb@sources.redhat.com, Vladimir Prus Subject: Re: frame cache Message-ID: <20070724181933.GA18953@caradoc.them.org> Mail-Followup-To: Michael Eager , gdb@sources.redhat.com, Vladimir Prus References: <46A63051.7060208@eagercon.com> <20070724171452.GA15843@caradoc.them.org> <46A6387F.8020303@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A6387F.8020303@eagercon.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00176.txt.bz2 On Tue, Jul 24, 2007 at 10:35:59AM -0700, Michael Eager wrote: > I don't see any links to the _frame_cache in frame_info. > I don't see anything in frame.c which looks like it searches > for the correct _frame_cache. Can you point me at the > right place? Sure: /* The frame's low-level unwinder and corresponding cache. The low-level unwinder is responsible for unwinding register values for the previous frame. The low-level unwind methods are selected based on the presence, or otherwise, of register unwind information such as CFI. */ void *prologue_cache; const struct frame_unwind *unwind; > When I put debugging code in _analyze_prologue(), I see > that it is called over and over while executing a "next" command. > All those bits going back and forth over the serial line to the > target. I like to use GDB's built in data caching and/or set trust-readonly-sections. I hope we can make the data caching more aggressive by default at some point. -- Daniel Jacobowitz CodeSourcery