multiple frame/register caches (or what isn't in GDB 6)

[Andrew Cagney]

Since GDB 6 is looming large, its probably time to think about what to 
not try and squeese into that release.

While the on-going architectural changes have many potential benefits, 
one more immediate and tangable addition is per-thread frame/register 
caches.

At present, when the user switches threads, GDB discards all local state 
(register cache, all frames, ...).  The plan is for GDB to instead 
maintain per-thread register/frame caches that are only flushed when the 
target changes.  For GUI environments, which like to switch between and 
display lots of threads, this should be a very big win.

Anyway, to give this an update.  The architecture methods are now 
[almost] all parameterized with an explicit frame/regcache, and that 
makes the addition of multiple active register/frame caches to core GDB 
just that much easier - the problem of architecture specific code 
indirectly manipulating global state is eliminated (see read_pc_pid).

The remaining obvious problems are of course read_pc_pid, and the target 
side supply_register.

So, don't expect this in GDB 6 :-)

enjoy,
Andrew