From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21396 invoked by alias); 1 Jul 2003 17:00:09 -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 21389 invoked from network); 1 Jul 2003 17:00:08 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sources.redhat.com with SMTP; 1 Jul 2003 17:00:08 -0000 Received: from nkelseyhome (12-235-58-117.client.attbi.com[12.235.58.117](untrusted sender)) by comcast.net (rwcrmhc11) with SMTP id <2003070117000601300585lae>; Tue, 1 Jul 2003 17:00:06 +0000 Message-ID: <00df01c33ff2$361e0b40$0a00a8c0@nkelseyhome> From: "Jafa" To: "Andrew Cagney" , References: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> <20030701034232.GB3434@nevyn.them.org> <00d001c33f8f$8cc48b30$0a00a8c0@nkelseyhome> <3F018586.8010209@redhat.com> <20030701140936.GA10877@nevyn.them.org> Subject: Re: Frame handling Date: Tue, 01 Jul 2003 17:00:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-07/txt/msg00023.txt.bz2 Hi Andrew, >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). Yeah, that was a bit of a mess :-) >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). Makes sense.... the trick is to leave this power to the port-specific code. The proposal in my last email still allows the port-writer to implement a light-weight frame_chain but I have to admit that it doesn't point them in that direction. Thanks for your time BTW - My view of the world is pretty small. Nick