[wip] Delete prev_func_name and ecs->stop_func_name
Andrew Cagney
ac131313@redhat.com
Wed Apr 16 14:28:00 GMT 2003
> 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
More information about the Gdb-patches
mailing list