Re: [PATCH] fix alias cache breakage

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

On Mon, 2008-07-14 at 15:33 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, Jul 14, 2008 at 01:58:58PM -0500, James Bottomley wrote:
> > [...]
> > > 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".  
> > 
> > Actually, the most likely case for an unresolved symbol is resolution in
> > another module rather than the kernel.
> 
> 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.

To give a concrete example:  SCSI depends intimately on the block layer.
The block request queue is actually cached in the SCSI device structure.
If I'm probing SCSI at certain points I want to see what the effect has
been on the block queue state, so I'll start with the SCSI symbol that
caches the queue.  If I can't resolve into block, I can't get at the
values.

There's nothing really magical about this ... gdb has to work in the
same way.

> > > Remember, we are about to start processing userspace binaries,
> > > likely in some shared dwflpp instances.  So "global" isn't.
> 
> > Then before you begin to do this, you need a namespace
> > discriminator.  The cache is global to the kernel namespace, so it
> > has to tie in to the kernel and its modules. [...]
> 
> 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).

The kernel and all its modules make up a single linked entity (a symbol
resolution can occur anywhere throughout them).

Likewise, a user process is another example of a linked entity.  A
process actually has shared objects which are basically  things that
belong to multiple linked entities.

declaration resolution could therefore be done by visiting the defining
symbol cache of all components of a linked entity until the symbol is
found.  However, there'd be tons of duplicates and it would be quite a
waste of space.  The most logical way of doing this is a single cache
per linked entity.

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

What I still need to know is how I get at the definition of the linked
entity?

James