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

[Daniel Jacobowitz <drow@mvista.com>]

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