From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16361 invoked by alias); 18 Mar 2002 17:52: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 16265 invoked from network); 18 Mar 2002 17:52:06 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 18 Mar 2002 17:52:06 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g2IHq6Q22570 for ; Mon, 18 Mar 2002 09:52:06 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 18 Mar 2002 09:51:42 -0800 Received: from [64.220.144.98] (vpn-scv-x2-213.apple.com [17.219.193.213]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g2IHq4v19576; Mon, 18 Mar 2002 09:52:04 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Mon, 18 Mar 2002 09:52:00 -0000 Subject: Re: Target changed, caching reg values in ``struct frame'' From: Jim Ingham To: Andrew Cagney , Klee Dienes , Keith Seitz , Jason Molenda , "Martin M. Hunt" CC: Message-ID: In-Reply-To: <3C93A965.9040500@cygnus.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2002-03/txt/msg00166.txt.bz2 On 3/16/02 12:21 PM, "Andrew Cagney" wrote: > 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. When we were doing performance analysis on Project Builder, one of the big time sinks we noticed for stepping was the call to -stack-list-frames. We weren't constructing arguments, this was just the accounting for saved registers, prologue parsing, etc... For very deep stacks (which most Object Oriented programs seem to always have) this was particularly bad. The problem, as I am sure you know, is that in a GUI you are always showing the stack, so you need to see if it has changed at every step. Any reliable algorithm for doing this involves counting the stack depth, and getting some kind of fingerprint of the stack. But there is no way to do this in gdb without building up the whole frame cache. Since most users never select stack frames above the top two or three when they are just stepping around, most of this is wasted work. I added a "ppc-fast-count-stack-depth" command to gdb (only for the PPC) which either counts the stack, or alternately lists duples of the pc & frame ptr for the stack. This command is pretty much of a hack in that it doesn't use any of the frame machinery, but just redoes the logic for PPC off to one side. But this gave us a noticeable boost in stepping speed - so as an experiment I think it indicates that providing a fast way to do this is very valuable. Having the frame pointer sent along is also nice because it is a very quick fingerprint of the stack. Remember for a GUI most of the time you really want to know just how much of the stack has changed - and for stepping the answer is usually "not much"... Another example (non-gui) where this is really expensive is in function calls deep in the stack. When somebody in ObjC goes to make a method call, we actually have to make several function calls into the inferior to bring this about (look up the selector, lookup the implementation function for the selector/object combo and finally call the implementation function). If you are doing this deep in the stack, you have to rebuild the frame cache up to the frame in whose context you are calling this after each call. This ends up being a substantial portion of the time for these method calls... Jim > > -- > > (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 > > -- ++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++= Jim Ingham jingham@apple.com Developer Tools - gdb