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

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