From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3952 invoked by alias); 24 Jul 2007 18:45:18 -0000 Received: (qmail 3944 invoked by uid 22791); 24 Jul 2007 18:45:18 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jul 2007 18:45:15 +0000 Received: (qmail 17309 invoked from network); 24 Jul 2007 11:45:13 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 24 Jul 2007 11:45:13 -0700 Message-ID: <46A648B9.3090201@eagercon.com> Date: Tue, 24 Jul 2007 18:45:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: frame cache References: <46A63051.7060208@eagercon.com> <20070724171452.GA15843@caradoc.them.org> <46A6387F.8020303@eagercon.com> <20070724181933.GA18953@caradoc.them.org> In-Reply-To: <20070724181933.GA18953@caradoc.them.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00180.txt.bz2 Daniel Jacobowitz wrote: > 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; I missed that prologue_cache ==> _frame_cache. I only saw that it was set by sentinel_frame_cache, but now I see that it is passed to frame_unwind_find_by_frame() and on from there. (Bad void pointer, bad, bad.) >> 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. Perhaps you or someone could write some documentation for this? :-) -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077