From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15134 invoked by alias); 24 Apr 2002 23:31:07 -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 15126 invoked from network); 24 Apr 2002 23:31:05 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by 209.249.29.67 with SMTP; 24 Apr 2002 23:31:05 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA14532; Wed, 24 Apr 2002 16:30:52 -0700 (PDT) Message-ID: <3CC73D58.2F9D2CF@redhat.com> Date: Wed, 24 Apr 2002 16:31:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: PATCH: per-inferior register cache for gdbserver References: <20020420132315.A20532@nevyn.them.org> <3CC1B811.5000304@cygnus.com> <20020420145943.A25321@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00984.txt.bz2 Daniel Jacobowitz wrote: > > 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. For what it's worth, I explored a lot of things like this (including exactly this, I think), when I was re-writing procfs.c. In the end, they resulted in no measurable performance improvement at all. ;-| But I had fun playing around with them, of course... Michael