From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5833 invoked by alias); 1 Jul 2003 14:57:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5823 invoked from network); 1 Jul 2003 14:57:11 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 1 Jul 2003 14:57:11 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D748E2B5F; Tue, 1 Jul 2003 10:57:06 -0400 (EDT) Message-ID: <3F01A142.8010603@redhat.com> Date: Tue, 01 Jul 2003 14:57:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jafa , gdb@sources.redhat.com Subject: Re: Frame handling References: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> <20030701034232.GB3434@nevyn.them.org> <00d001c33f8f$8cc48b30$0a00a8c0@nkelseyhome> <3F018586.8010209@redhat.com> <20030701140936.GA10877@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00020.txt.bz2 > Um, this is still dangling. Can you please express your question using >> terminology consistent with the frame unwind code. > > > I think Nick's question is: why does every architecture implement the > cache lazily, instead of GDB instructing the architecture when to > create the cache. (I'm honestly not so sure, I think there is more). For this question, it's a case of learning from past mistakes. See legacy_get_prev_frame. The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed. General confusion over what was ment to happen when quickly exploded into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC, INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to initialize the cache[s] (there ended up being three!) but many, such as FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they didn't even have access to the cache). The new code takes the oposite approach. Only specify interfaces that are absolutly needed and make the unwinder 100% responsible for all cache management, populating it based on the immediate demand. One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing prologue analysis). It may be possible to implement this in the new unwinders - id_unwind would only create/populate what was immediatly necessary and avoid a full prologue analysis (something that is considered expensive). Andrew