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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 03 Sep 2010 17:59:16 +0200, Doug Evans wrote:
> 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?)

This means only one CU is guaranteed to be read in at one time.  And when you
hold that CU you must not call any GDB function as this function can (upon
a change in the future) request its own CU and thus invalidate CU at the
caller.  I find it as a too fragile policy.

Still I find it even ineffective.  Regular aging means CUs get flushed even if
only a few of them is now read-in.


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

The aging currently affects all CUs read-in.  There can be several nested
calls each requesting its own CU and doing aging at the (inner) cleanup time.
That means a cleanup in the inner call may age-out CU in the outer call still
before the outer cleanup.

Without any CU locking in place I still do not see a safe point other than at
the top level idle time (that is prepare_execute_command).


Thanks,
Jan