* multiple frame/register caches (or what isn't in GDB 6)
@ 2003-06-06 20:02 Andrew Cagney
0 siblings, 0 replies; only message in thread
From: Andrew Cagney @ 2003-06-06 20:02 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2003-06-06 20:02 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-06 20:02 multiple frame/register caches (or what isn't in GDB 6) Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).