From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-46409-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 16637 invoked by alias); 30 Nov 2006 01:04:53 -0000
Received: (qmail 16626 invoked by uid 22791); 30 Nov 2006 01:04:52 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Nov 2006 01:04:44 +0000
Received: (qmail 15355 invoked from network); 30 Nov 2006 01:04:42 -0000
Received: from unknown (HELO localhost) (jimb@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 30 Nov 2006 01:04:42 -0000
To: Jean-Marc Saffroy <saffroy@gmail.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] gdb script performance
References: <Pine.LNX.4.64.0611300025340.5248@erda.mds>
From: Jim Blandy <jimb@codesourcery.com>
Date: Thu, 30 Nov 2006 01:04:00 -0000
In-Reply-To: <Pine.LNX.4.64.0611300025340.5248@erda.mds> (Jean-Marc Saffroy's message of "Thu, 30 Nov 2006 01:33:02 +0100 (CET)")
Message-ID: <m38xhtagmk.fsf@codesourcery.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-11/txt/msg00413.txt.bz2


Jean-Marc Saffroy <saffroy@gmail.com> writes:
> Index: gdb-6.5-prof/gdb/symtab.c
> ===================================================================
> --- gdb-6.5-prof.orig/gdb/symtab.c	2006-11-29 03:27:18.000000000 +0100
> +++ gdb-6.5-prof/gdb/symtab.c	2006-11-29 03:27:20.000000000 +0100
> @@ -2022,8 +2022,8 @@
>  /* Find the symtab associated with PC and SECTION.  Look through the
>     psymtabs and read in another symtab if necessary. */
>
> -struct symtab *
> -find_pc_sect_symtab (CORE_ADDR pc, asection *section)
> +static struct symtab *
> +find_pc_sect_symtab_uncached (CORE_ADDR pc, asection *section)
>  {
>    struct block *b;
>    struct blockvector *bv;
> @@ -2123,6 +2123,24 @@
>    return (s);
>  }
>
> +struct symtab *
> +find_pc_sect_symtab (CORE_ADDR pc, asection *section)
> +{
> +  static CORE_ADDR cached_pc;
> +  static asection *cached_section;
> +  static struct symtab *cached_symtab;
> +  static int try_cache = 0;
> +
> +  if (try_cache && (cached_pc == pc) && (cached_section == section))
> +    return cached_symtab;
> +
> +  try_cache = 1;
> +  cached_pc = pc;
> +  cached_section = section;
> +  cached_symtab = find_pc_sect_symtab_uncached (pc, section);
> +  return cached_symtab;
> +}
> +
>  /* Find the symtab associated with PC.  Look through the psymtabs and
>     read in another symtab if necessary.  Backward compatibility, no section */

When the user changes the symbol file (or when GDB notices it has
changed and automatically re-reads it), the section and symtab objects
your static variables are pointing to will be freed.  If you then get
a spurious cache hit, you'll hand out a pointer to garbage.  So you'll
need to invalidate the cache whenever the section or symtab get freed.