From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7841 invoked by alias); 18 Mar 2002 19:51:32 -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 7773 invoked from network); 18 Mar 2002 19:51:19 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 18 Mar 2002 19:51:19 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C7B413ED3; Mon, 18 Mar 2002 14:51:14 -0500 (EST) Message-ID: <3C964532.3000302@cygnus.com> Date: Mon, 18 Mar 2002 11:51: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: Jim Ingham Cc: Klee Dienes , Keith Seitz , Jason Molenda , "Martin M. Hunt" , gdb@sources.redhat.com Subject: Re: Target changed, caching reg values in ``struct frame'' References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00169.txt.bz2 > 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. Ah (I didn't know :)! > 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. If this were to be done in a generic fashion, the trick might be to make the frame evaluation very lazy - evaluate something only when it is explicitly requested (current implementations would stick to the current heavy handed approach though). I suspect that GDB was once trying to do this (the badly defined read_fp() and a few other functions) but the technique has been lost (or made impossible by frame prologues). The dwarf2 stuff should help. > 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"... Yes. As you mentioned above, both ``stop address'' and ``frame address'' are needed. I don't think GDB currently does a good job on this front - it tends to only do comparisons based ``frame'' :-( > 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... Outch! I'd not even considered this. Sounds like just concentrating on run/stop (stepi, inferior call, ...) and ignoring memory writes is a good move. thanks for this! Andrew