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

[Andrew Cagney <ac131313 at redhat dot 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.

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