Re: [wip] Delete prev_func_name and ecs->stop_func_name

[Daniel Jacobowitz <drow@mvista.com>]

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.  But matching the
execution count for the line after the goto is suspicious.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer