From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12735 invoked by alias); 20 Apr 2002 18:59:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12727 invoked from network); 20 Apr 2002 18:59:22 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 20 Apr 2002 18:59:22 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16z05H-0006dn-00; Sat, 20 Apr 2002 14:59:43 -0400 Date: Sat, 20 Apr 2002 11:59:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: per-inferior register cache for gdbserver Message-ID: <20020420145943.A25321@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020420132315.A20532@nevyn.them.org> <3CC1B811.5000304@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC1B811.5000304@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00686.txt.bz2 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