From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3081 invoked by alias); 16 Apr 2002 16:14:17 -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 3049 invoked from network); 16 Apr 2002 16:14:13 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 16 Apr 2002 16:14:13 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA19063; Tue, 16 Apr 2002 09:14:11 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3GGE6d30807; Tue, 16 Apr 2002 09:14:06 -0700 Date: Tue, 16 Apr 2002 09:14:00 -0000 From: Kevin Buettner Message-Id: <1020416161406.ZM30806@localhost.localdomain> In-Reply-To: Andrew Cagney "[rfc] Frame based register cache / frame->unwind" (Apr 14, 4:58pm) References: <3CB9ED82.8050007@cygnus.com> To: Andrew Cagney , gdb@sources.redhat.com Subject: Re: [rfc] Frame based register cache / frame->unwind MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00267.txt.bz2 On Apr 14, 4:58pm, Andrew Cagney wrote: > I'm not too worried about the apparent 2% overhead per frame create > though. With the patch applied, the code ends up maintaining both this > new cache and the old ->saved_regs table. Rewriting a target to just > use the ->unwind_cache, should, I think, claw back the 2% and then some > - less need to go out to the target. I'm puzzled. Assuming you don't have dwarf2cfi or the like, how do you avoid maintaining the old ->saved_regs table? Hmm... I see that the unwind cache has an ``addr'' field. Does that mean that that the prologue analysis function calls frame_supply_unwound_register() to set this field? What is the ``optimized'' flag (in the frame cache) used for? Kevin