From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31279 invoked by alias); 16 Apr 2003 14:28:42 -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 31255 invoked from network); 16 Apr 2003 14:28:41 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 16 Apr 2003 14:28:41 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1F1E42B2F; Wed, 16 Apr 2003 10:28:42 -0400 (EDT) Message-ID: <3E9D689A.2010803@redhat.com> Date: Wed, 16 Apr 2003 14:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [wip] Delete prev_func_name and ecs->stop_func_name References: <3E9CDC25.9060100@redhat.com> <20030416133745.GA6991@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00320.txt.bz2 > 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. Andrew