* [wip] Delete prev_func_name and ecs->stop_func_name
@ 2003-04-16 4:29 Andrew Cagney
2003-04-16 13:37 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-04-16 4:29 UTC (permalink / raw)
To: gdb-patches
Hello,
`what smokin gun?'
More follow-up on prev_pc, I decided to just delete prev_func_name and
ecs->stop_func_name and see what happens ...
Briefly ....
When identifying a PC in a signal trampoline, GDB uses a sequence like:
find_pc_partial_function (get_frame_pc (frame), &name,
(CORE_ADDR *) NULL, (CORE_ADDR *)
NULL);
PC_IN_SIGTRAMP (get_frame_pc (frame), name)
(map the PC onto a function name) where PC_IN_SIGTRAMP then contains
something like:
if (SIGTRAMP_START_P ())
return (pc) >= SIGTRAMP_START (pc) && (pc) < SIGTRAMP_END (pc);
else
return name && strcmp ("_sigtramp", name) == 0;
use that function name to see if it is in the sigtramp function.
GDB contains two tweaks for improving performance:
- find_pc_partial_function() runs a single entry cache so that second
and further requests for the same function, are handled without any
symbol table lookup
- infrun.c caches (well tries to) the results (in prev_func_name) and
(ecs->stop_func_name) from the find_pc_partial_function() lookup to
avoid additional calls.
If prev_func_name and stop_func_name are eliminated, infrun.c will make
additional calls to find_pc_partial_function(). That, I think, is ok,
provided the hit rate of find_pc_partial_function's cache doesn't go down.
So ....
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;
That is, while the calls to find_pc_sect_partial_function were increased
by 2000 the number of misses (which resulted in expensive symbol table
lookups) increased by, er, 4!!
Given this, my conclusion is that prev_func_name and ecs->stop_func_name
can be deleted. The the cost incured is an additional function call and
not the very expensive PC->symbol lookup.
The more bits of infrun that get deleted the better :-)
thoughts?
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [wip] Delete prev_func_name and ecs->stop_func_name
2003-04-16 4:29 [wip] Delete prev_func_name and ecs->stop_func_name Andrew Cagney
@ 2003-04-16 13:37 ` Daniel Jacobowitz
2003-04-16 14:28 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Jacobowitz @ 2003-04-16 13:37 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [wip] Delete prev_func_name and ecs->stop_func_name
2003-04-16 13:37 ` Daniel Jacobowitz
@ 2003-04-16 14:28 ` Andrew Cagney
2003-04-16 14:43 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-04-16 14:28 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [wip] Delete prev_func_name and ecs->stop_func_name
2003-04-16 14:28 ` Andrew Cagney
@ 2003-04-16 14:43 ` Daniel Jacobowitz
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Jacobowitz @ 2003-04-16 14:43 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-04-16 14:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-16 4:29 [wip] Delete prev_func_name and ecs->stop_func_name Andrew Cagney
2003-04-16 13:37 ` Daniel Jacobowitz
2003-04-16 14:28 ` Andrew Cagney
2003-04-16 14:43 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox