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


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


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