This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: Prologue cache fix
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: RFA: Prologue cache fix
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Mon, 06 Mar 2000 15:18:52 -0500
- CC: Fernando Nasser <fnasser at redhat dot com>, gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat , Inc. - Toronto
- References: <38B4073E.281C4CE0@redhat.com> <38BB65F6.44D991A2@cygnus.com>
Andrew Cagney wrote:
>
> Fernando Nasser wrote:
> >
> > This patch fixes a problem that happens when gdb reconnects to a
> > target. Targets that have a prologue cache must invalidate its contents
> > or they can assume wrong things based on stale data.
>
> I'm wondering when exactly this prologue_cache provides real benefit?
>
So do I. I have tried to track down the history of this but it was lost in a merge of old...
The FR30 target has the same cache and I am not sure were the first version appeared.
> The only other possibility I can think of is is something like an
> inferior function call where GDB comes back to that exact same address.
> For a recursive call, the register info would be wrong.
>
> So anyone enlighten me as to when exactly this thing kicks in? :-)
>
The author justified this with the following comment:
/* (...) When performing
a backtrace, GDB will usually ask to scan the same function twice
in a row (once to get the frame chain, and once to fill in the
extra frame information). */
This would slow backtraces on targets with slow comm links.
Maybe the right fix should have been prevent the two calls in the first place. But, if I am not mistaken, this is not
trivial. So, the author came with this cache.
I wonder if the author thought of recursion. At a first sight it seems wrong.
> If the prologue_cache is purged at the same time as the frame obstack
> then the two have the same lifetime. If that is the case then I think
> that the prologue analysis might as well be left in the frame object in
> ``struct frame_extra_info''.
>
Seems more logical.
I vote to eliminate the prologue cache (as it seems that it has at least two serious bugs) and cope with the performance
penalty until a valid optimization is found.
What do you think?
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299