Re: [patch] Fix DW_OP_call2 and DW_OP_call4 for max-cache-age 0

[Doug Evans <dje@google.com>]

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.)