This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: Jim Blandy <jimb at cygnus dot com>, Petr Sorfa <petrs at caldera dot com>,Daniel Jacobowitz <drow at mvista dot com>, gdb at sources dot redhat dot com
- Date: Mon, 04 Feb 2002 20:13:12 -0500
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- References: <Pine.LNX.4.44.0202041203250.26583-100000@dberlin.org>
>
>
> Here's a question to think about as we move towards that:
> Where should the cache be?
>
> If you are using oft-computed expressions, we should be able to cache them
> if the information they depend on hasn't changed.
>
> Should each thing that implements the functions above handle caching
> internally, or should we put it one level above, and add functions to make
> generic queries like "is this location going to change if the x
> register changes".
>
> Assuming the queries are cheap, you could simply walk the changed
> values in the frame, ask if if any matter, and if not, you don't need
> to redo the calculation/value.
Relatively speaking I'd expect it to be cheap.
The most common case of something changing is when the target is
resumed. For this case, GDB has to invalidate everything and start
again from scratch. Hence, this is the case GDB needs to have working
fast. Initially, at least, register and memory writes can just be
treated like target resumes - target-changd.
Supporting this is varobj (well what I understand of it) Varobj tracks
variables identifying those that changed. It then provides a refresh
list to the UI (Insight or MI). While the computation necessary to
identify changed variables is singificant, it is nothing when compared
to the overhead of refreshing a variable's value on the screen. By
avoiding unnecessary refreshes, performance is significantly improved.
The other thing is that GDB has plenty of easier fixes when it comes to
caching: not flushing the cache when switching threads; pre-fetching
memory; ....
Anyway, as they say, get it working, then get it working fast; A slow
program shipped today is still quicker than a fast program shipped
tomorrow; ... :-^
--
Jim,
to throw a question in here. Where does this overall change leave
$frame? I'm suspecting that the existing frame code ends up being
pushed sideways and down covered by a new layer that lets you get at the
above.
enjoy,
Andrew