From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10825 invoked by alias); 10 Mar 2002 05:54:50 -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 10551 invoked from network); 10 Mar 2002 05:54:46 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 10 Mar 2002 05:54:46 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8AE473E0B; Sun, 10 Mar 2002 00:54:41 -0500 (EST) Message-ID: <3C8AF521.9080704@cygnus.com> Date: Sat, 09 Mar 2002 21:54:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Klee Dienes Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Cached function lookup References: <8A9ABA76-1A1B-11D6-BA6D-0030653FA4C6@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00132.txt.bz2 > This patch allows functions in the target used by GDB ("malloc", > "scm_lookup_cstr", and later a ton of Objective-C functions) to have > their values cached and re-used unless the symbol table has changed > in-between calls. This is a performance win overall, and a particular > win when dispatching Objective-C method calls and looking up > Objective-C type information from the runtime. For the breakpoint changes, assuming that the function-cache code is committed, can the two declarations: > +extern unsigned int symbol_generation; > + > /* Interface: */ > /* Clear a bpstat so that it says we are not at any breakpoint. > Also free any storage that is part of a bpstat. */ > @@ -525,6 +527,8 @@ > extern int breakpoint_thread_match (CORE_ADDR, ptid_t); > > extern void until_break_command (char *, int); > + > +extern void breakpoint_update (void); be removed (made static)? Can I suggest adding a comment explaining that the re_set is delayed until the breakpoints are re-inserted. > extern void breakpoint_re_set (void); Hmm, I can think of two race conditions: o with the function-cache code - I don't think this matters - the cache is always flushed flushed before breakpoint code does the update (and the breakpoint code doesn't actually use the function cache (?)). o with things like ``info breakpoints'' Do those functions also need to breakpoint_update()? enjoy, Andrew