From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7888 invoked by alias); 16 Apr 2002 17:08:57 -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 7842 invoked from network); 16 Apr 2002 17:08:55 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Apr 2002 17:08:55 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5113D3C71; Tue, 16 Apr 2002 13:09:02 -0400 (EDT) Message-ID: <3CBC5AAD.1040106@cygnus.com> Date: Tue, 16 Apr 2002 10:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: [rfc] Frame based register cache / frame->unwind References: <3CB9ED82.8050007@cygnus.com> <1020416161406.ZM30806@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00268.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? Old code would have ->saved_registers. Newer code could pre-load the cache instead of ->saved_registers. The case I considered here was SP where ->saved_registers contains the value and not the address. Added the function frame_supply_unwound_register() with that in mind. The others are ``addresses'' though. The cache would need tinkering for this to work - capable of recording the ``address'' and/or the value. The frame_supply_unwound_register() (unused) was a step in that direction. > 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? Yes, that is what I had in mind. But see above, it needs tinkering. > What is the ``optimized'' flag (in the frame cache) used for? Grep for OPTIMIZED, it is used but it probably isn't applicable to registers. I just cache everything :-) There should probably be an ``unavailable'' indication instead, I'm not trying to change that part of the code though. (There is a register_valid() call that isn't reliable.) thanks! Andrew