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

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

[Andrew Cagney]

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

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

[Jim Ingham]

On 3/16/02 12:21 PM, "Andrew Cagney" <ac131313@cygnus.com> 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

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

[Andrew Cagney]

> 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