This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix DW_OP_call2 and DW_OP_call4 for max-cache-age 0
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches at sourceware dot org
- Date: Fri, 3 Sep 2010 17:39:55 +0200
- Subject: Re: [patch] Fix DW_OP_call2 and DW_OP_call4 for max-cache-age 0
- References: <20100823185008.GA2926@host1.dyn.jankratochvil.net> <AANLkTimhw307GT1dxA5LFBnCA1njK1vk4+Sk8oamafkX@mail.gmail.com> <20100902160216.GA10848@host1.dyn.jankratochvil.net> <m3hbi66drd.fsf@fleche.redhat.com>
On Fri, 03 Sep 2010 17:35:50 +0200, Tom Tromey wrote:
> I don't get the rationale for putting it in prepare_execute_command.
> If we are flushing the cache based on memory use, then we only need to
> consider flushing it just before we read a CU.
There is currently no way of "locking" CUs. Some processing may arbitrarily
access more and more CUs, and even the previous ones. Processing may need
generally unlimited number of CUs, therefore it can reach the limit and flush
still referenced CU.
Therefore I find prepare_execute_command as the only safe place to flush any
CU.
(I may miss there exist some more strict rules than I am aware of.)
Thanks,
Jan