[PATCH] fix alias cache breakage

Frank Ch. Eigler fche@redhat.com
Mon Jul 14 18:50:00 GMT 2008


Hi -

On Mon, Jul 14, 2008 at 12:47:55PM -0500, James Bottomley wrote:
> [...]
> > 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. 

I understand that, but an implicit heuristic like that will not work
in general.  What we could do is hardcode a "cache miss in a module?
then search vmlinux - if available".  Remember, we are about to start
processing userspace binaries, likely in some shared dwflpp instances.
So "global" isn't.

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

It was only a coincidence if we might have iterated through other CUs
before starting to resolve any particular forward-declared $variable.
It would be better to nest an explicit CU-loop at that time.

> > 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?

I think so.  (And that cu cache better be per-module. :-)


- FChE



More information about the Systemtap mailing list