Re: Target changed, caching reg values in ``struct frame''

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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