From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28149 invoked by alias); 24 Jul 2007 17:36:07 -0000 Received: (qmail 28140 invoked by uid 22791); 24 Jul 2007 17:36:07 -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 17:36:02 +0000 Received: (qmail 29631 invoked from network); 24 Jul 2007 10:36:00 -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 10:36:00 -0700 Message-ID: <46A6387F.8020303@eagercon.com> Date: Tue, 24 Jul 2007 18:10:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Michael Eager , gdb@sources.redhat.com, Vladimir Prus Subject: Re: frame cache References: <46A63051.7060208@eagercon.com> <20070724171452.GA15843@caradoc.them.org> In-Reply-To: <20070724171452.GA15843@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/msg00174.txt.bz2 Thanks for the quick reply. Daniel Jacobowitz wrote: > On Tue, Jul 24, 2007 at 10:01:05AM -0700, Michael Eager wrote: >> I have a couple questions about the _frame_cache >> structure and functions. >> >> 1) This appears to be a single-entry cache. Why not keep >> multiple entries? > > No, it isn't single-entry. The common code in frame.c is responsible > for passing a pointer to the correct place to store the cache for the > current frame. 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? >> 2) The data in the frame cache seems to be of two different >> types: >> a) Fixed, based on analyzing the code: register offsets, >> stack alignment, framelessness, etc. >> b) Variable, based on the call: return pc, frame base >> >> It looks to me that the object code is analyzed repeatedly >> and this fixed information is discarded along with the >> variable information. >> >> Why not keep a persistent cache of function specific fixed >> data and only discard the call-specific data when the frame >> cache is cleared? > > No good reason. I have thought about doing this before. It's not > fundamentally different from the way the DWARF unwinder works; the > persistent part of the cache would be approximately an FDE. It's a > little tricky to implement, since we still need to detect stopping > within the prologue, but not too tricky. I suppose bonus points would > be awarded for constructing an actual FDE :-) I don't know about creating FDEs, but keeping persistent data like frame pointer and size should be simple. 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. >> Is there any documentation about what target-specific data >> the frame cache is supposed to contain or how the functions are >> supposed to work? > > Not really, because it's completely up to the target what goes in > them; it varies quite a bit between targets. > > Vlad, didn't you say a week or two ago that you'd been working on some > frame docs? I'd appreciate anything, naturally. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077