This is the mail archive of the
mailing list for the GDB project.
Re: RFA: Prologue cache fix
- To: Fernando Nasser <fnasser at redhat dot com>
- Subject: Re: RFA: Prologue cache fix
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 29 Feb 2000 17:23:50 +1100
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <38B4073E.281C4CE0@redhat.com>
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?
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
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? :-)
> 2000-02-23 Fernando Nasser <email@example.com>
> * gdbint.texinfo: Add entry for target dependent macro
> *** blockframe.c 1999/12/22 21:45:03 18.104.22.168
> --- blockframe.c 2000/02/23 00:17:15
> *************** flush_cached_frames ()
> *** 269,274 ****
> --- 269,277 ----
> current_frame = NULL; /* Invalidate cache */
> select_frame (NULL, -1);
> + #ifdef FLUSH_PROLOGUE_CACHE
> + FLUSH_PROLOGUE_CACHE ();
> + #endif
> annotate_frames_invalid ();
As an asside, this won't work well with multi-arch.