This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFA: Prologue cache fix


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]