This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] fix alias cache breakage
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