From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11475 invoked by alias); 16 Apr 2003 14:43:38 -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 11455 invoked from network); 16 Apr 2003 14:43:38 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Apr 2003 14:43:38 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 195o8Z-0008Gc-00; Wed, 16 Apr 2003 09:43:48 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 195o8N-0002e4-00; Wed, 16 Apr 2003 10:43:35 -0400 Date: Wed, 16 Apr 2003 14:43:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [wip] Delete prev_func_name and ecs->stop_func_name Message-ID: <20030416144335.GA10153@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3E9CDC25.9060100@redhat.com> <20030416133745.GA6991@nevyn.them.org> <3E9D689A.2010803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9D689A.2010803@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00323.txt.bz2 On Wed, Apr 16, 2003 at 10:28:42AM -0400, Andrew Cagney wrote: > >On Wed, Apr 16, 2003 at 12:29:25AM -0400, Andrew Cagney wrote: > > > >>Running the i386 testsuite with gcov on an existing GDB reveals: > >> > >> int > >> find_pc_sect_partial_function > >> 10133 { > >> 10133 struct partial_symtab *pst; > >> struct symbol *f; > >> struct minimal_symbol *msymbol; > >> struct partial_symbol *psb; > >> struct obj_section *osect; > >> int i; > >> CORE_ADDR mapped_pc; > >> > >> 10133 mapped_pc = overlay_mapped_address (pc, section); > >> > >> 10133 if (mapped_pc >= cache_pc_function_low > >> && mapped_pc < cache_pc_function_high > >> && section == cache_pc_function_section) > >> 3565 goto return_cached_value; > >> > >> 3565 if (SIGTRAMP_START_P () && ... > >> > >>that is, 10133 calls to find_pc_sect_partial_function, 3565 of which > >>missed in the cache. Modifying infrun.c so that it doesn't cache the > >>name turns up: > >> > >> int > >> find_pc_sect_partial_function > >> 12087 { > >> 12087 struct partial_symtab *pst; > >> struct symbol *f; > >> struct minimal_symbol *msymbol; > >> struct partial_symbol *psb; > >> struct obj_section *osect; > >> int i; > >> CORE_ADDR mapped_pc; > >> > >> 12087 mapped_pc = overlay_mapped_address (pc, section); > >> > >> 12087 if (mapped_pc >= cache_pc_function_low > >> && mapped_pc < cache_pc_function_high > >> && section == cache_pc_function_section) > >> 3569 goto return_cached_value; > > > > > >What're the following lines for both of these? There's some > >optimization at work here, or these numbers show the exact opposite of > >what you want. That's 3569 _hits_ to the cache. > > No. > > > But matching the > >execution count for the line after the goto is suspicious. > > It's gcov playing tricks, the goto is being counted in the false path. > The first analysis illustrates this: > > >>> 3565 goto return_cached_value; > >>> > >>> 3565 if (SIGTRAMP_START_P () && ... > > and the second is identical. In that case, go for it! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer