This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [wip] Delete prev_func_name and ecs->stop_func_name
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 16 Apr 2003 09:37:45 -0400
- Subject: Re: [wip] Delete prev_func_name and ecs->stop_func_name
- References: <3E9CDC25.9060100@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. But matching the
execution count for the line after the goto is suspicious.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer