From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7893 invoked by alias); 16 Mar 2002 20:22:06 -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 7850 invoked from network); 16 Mar 2002 20:22:03 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 16 Mar 2002 20:22:03 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9AAFA3EC1; Sat, 16 Mar 2002 15:21:57 -0500 (EST) Message-ID: <3C93A965.9040500@cygnus.com> Date: Sat, 16 Mar 2002 12:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Klee Dienes , Jim Ingham , Keith Seitz , Jason Molenda , "Martin M. Hunt" Cc: gdb@sources.redhat.com Subject: Target changed, caching reg values in ``struct frame'' Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00154.txt.bz2 Hello, (I think this is more of an issue to GUI developers so I've directly pinged a few :-) GDB has tried to improve its performance by having a number of target-changed (from target stopping) events. For instance registers-changed (write to register) and possibly memory-changed (write to variable). I've suggested previously that these refined events were not worth the effort. If the programmer modifies something in the target (a rare event in its self, I don't remember the last time I modified the target) then it is definitly easier and simplier (and hopefully almost as fast) to just throw away GDB's local copy of the target's state and start again. My question for the GUI people is, does any one have evidence supporting this? Should GDB only concentrate on trying to tune target-changed (single step) performance and completly ignore the other cases (eliminating register-changed and anything else). I know the Insight developers have so far concentrated on stepi. -- (What is the secret plan?) GDB has two types of registers: - raw registers as found in the register cache - frame registers as found via struct frame Frame registers are constructed from raw-registers, memory, or the next inner most frame. Would there be any performance gain in having ``struct frame'' cache the raw byte value of a frame register? At present the frame contains the address of the saved register (for traditional frame code) (I'm not sure what it does for CFI frames). I'm thinking that a key part of recovering from a stepi is the reconstruction of the ``struct frame'' chain. Again, anyone got evidence supporting this? -- enjoy Andrew