Re: [PATCH] fix alias cache breakage

[James Bottomley <James dot Bottomley at HansenPartnership dot com>]

On Mon, 2008-07-14 at 17:19 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, Jul 14, 2008 at 04:02:35PM -0500, James Bottomley wrote:
> > [...]
> > > OK, that makes it even worse a candidate for the heuristic.  So IMO
> > > the automatic alias cache business should stop at the point where it
> > > searches other CUs in the same module.
> > 
> > Like I said, it can't.  This is a debugger.  You probe in the module
> > where the operation you're interested is complete, but you need
> > information on the symbols you find there that depend on other things in
> > the stack. [...]
> 
> Of course.  Note that I said *automatic*.
> 
> 
> > > User namespaces wouldn't be so straightforward; neither shared
> > > libraries or executables would be a proper key for namespaces that are
> > > intended to be complete.
> >
> > OK ... you're thinking compiler namespaces.  I was thinking symbol
> > resolution namespaces.  Think of them more like linked entites
> > (something that when entirely linked and resolved comprises the
> > programme). [...]
> 
> But this linking can be an entirely run-time (dynamic) phenomenon.

So you handle it like gdb ... you can mark symbols for later resolution
if the shared object comes along.

> > > Once we need to leave the confines of a single module to resolve type
> > > names, the script will need to give help in naming types & contexts.
> > > At that point, we might as well implement general casting.  See
> > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=6704#c1 for a
> > > possible syntax to implement as part of bug #5634.
> 
> > your cast2 function will probably be making use of the alias cache
> > anyway, so this is part way towards that.
> 
> I don't want to think in terms of any cache as the defining or
> enabling characteristic of anything.  There will have to be
> cross-module type lookup, and however that's implemented is fine.
> Note that this @cast2() widget requires the script to identify the
> module in whose scope to look up the target type.  So we would may not
> need *automatic* searches along the lines of your original
> global_alias_cache, nor a compile-time notion of "namespace" or
> "linked entity".

The operation of traversing CUs to get defining dies is expensive.  Once
done for a module (or module+cu) it doesn't want to be done again.  Thus
to mitigate this, the found dies need caching.  The logical scope for
such a cache cache is the linked entity  ... unless you're suggesting we
just search all the CUs every time we need a declaration?  Even then,
there still needs to be a cache of CUs telling us where to look.

> > What I still need to know is how I get at the definition of the
> > linked entity?
> 
> I believe one doesn't exist statically, in general.

So how do you distinguish in a mixed probe environment between user
space processes and the kernel?

James