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

[Andrew Cagney <ac131313 at cygnus dot com>]

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