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
On Fri, Sep 3, 2010 at 8:39 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> 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.
Unless code that needs a CU reads it in as necessary, and the API into
the dwarf reader only ages the cache at well defined points that no
longer need CUs (e.g. when we're done psymtab->symtab expansion).
(right?)
> Therefore I find prepare_execute_command as the only safe place to flush any
> CU.
OOC, If we did move cache aging to a higher level, is there a reason
it can't be done at cleanup time?
[For reference sake, it's actually done today for free_stack_comp_unit.]
> (I may miss there exist some more strict rules than I am aware of.)