Re: PATCH: per-inferior register cache for gdbserver

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Apr 20, 2002 at 02:48:49PM -0400, Andrew Cagney wrote:
> >Moving right along.  This is the initial per-inferior register cache
> >interface; in my development sources (which are almost ready for
> >submittal) the interface is actually somewhat different, but that's
> >entangled with the rest of threading right now.  I'll be extracting it in
> >the next few days.
> >
> >So, this patch is a step on the road, but don't get too attached to the
> >interface.  It'll be much nicer, I promise.  This version works as-is, 
> >which
> >I can't say for the nicer one at the moment.
> 
> Um, would there be more benefit in getting this sort of thing 
> implemented in the core of GDB?  I just don't see a per-lwp cache in the 
> remote target making much difference to GDB's thread debugging performance.

There would be more benefit in doing it in GDB, certainly.  But like a
lot of optimizations I'm doing in the server right now, this is
beneficial to the server itself.  Note that I completely replaced the
global cache; I switch back and forth amongst LWPs during operations,
sometimes.  It simplifies life in the server greatly if I can just say
"give me this thread's current registers" and let the register cache
handle the details.

In GDB, this would be a performance optimization; in the server it's
there for simplicity more than anything else.  It also lets me delay
register fetching for other threads until it's actually needed, which
it may never be (in the next version of the cache, which has valid
flags).  I can get numbers later on how many register fetches it
actually saves; I suspect it's fairly small.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer