This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fix alias cache breakage


On Mon, 2008-07-14 at 13:36 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, Jul 14, 2008 at 11:13:58AM -0500, James Bottomley wrote:
> > PR6739: speed up decl-alias cache by avoiding its recomputation;
> > move to per-module/cu
> 
> > Actually completely broke the alias cache.  [...later...]  I also
> > updated the test to make it actually work (the reason why this
> > breakage was only spotted running a script, not running the
> > tests). [...]
> 
> Right, that's why we need good test cases.
> 
> > The reason is that we have to cross CUs to do resolution of
> > DW_AT_declaration.  If it could be resolved within the CU, the
> > compiler wouldn't have stubbed the declaration.
> 
> OK.
> 
> > It seems that the intent of this change (although never discussed on
> > the mailing list)
> 
> The problem was summarized on the mailing list.
> (http://sourceware.org/ml/systemtap/2008-q3/msg00148.html)
> 
> > was to only run the cache addition once per CU in the interests of
> > efficiency.  This update actually fixes the alias cache again, while
> > preserving that goal.
> 
> I see what you're getting at, but having a single "global" array is
> still wrong; it needs to be at least module-indexed.

Not for global declarations.  It's not inconceivable that the only
resolution of the structure is in a separate module.  The compiler will
drop a DW_AT_declaration if the CU never uses the structure.  Even if an
entire module doesn't use the structure, you might still want to use it
for debugging. 

>   Further, it is
> undesirable to speculatively tabulate all those definitions even if we
> don't actually encounter unresolved decls, which is why my version
> moved the traversal to the moment of a "cache miss".

This I would agree with.  The problem is that by the time you know you
need to do a lookup, all the other information has gone past.

> So, it seems that the declaration_resolve() function is still the
> right place to trigger the search; and that it should iterate over
> CU's too and compute a union of found name->die entries.

Then what would have to be done is to cache all the CUs and iterate over
them filling in the global alias cache when the resolution is needed ...
will that do?

James



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]