Re: [PATCH] fix alias cache breakage

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

On Tue, 2008-07-15 at 10:19 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, Jul 14, 2008 at 05:46:39PM -0500, James Bottomley wrote:
> > [...]
> > > > 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.
> 
> Not quite - we don't have the luxury of stopping a target program at
> the moment of a breakpoint, rummaging around its then-current shared
> library mappings, parse their associated debuginfo, and attempt type
> resolution then.
> 
> 
> > [...]  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 [...]
> 
> Simply caching by module is fine.  We'd only need a "linked entity"
> concept if we were to have an automated search path between these
> per-module caches.

No ... it's a scoping thing ... we need to know which modules to search
for a symbol.  You don't want to be searching the kernel CUs for a user
space symbol (or vice versa), so the list of searchable caches needs to
be done at the linked entity level.  You can populate them only when you
begin a search, but you still need to know where to look.

It sort of really sounds like an include keyword might be the best way.
That would insert nicely into the current framework at the same level as
probe and have a similar syntax:

include kernel

or

include module("<module>")

and simply populate the search list.

> > > > 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?
> 
> It depends on what exactly you mean.  For knowing how (kprobes vs.
> uprobes) to insert probes, we know that from the probe point syntax.
> For knowing *where*, we have a combination of static symbol tables,
> and run-time data like relocation bases, and the changing memory maps
> of user processes.  For knowing what variables are available, we get
> that from the probe points syntax too, since they'd identify the dwarf
> data.  For types, it's wide open - we will probably cast pointers to
> any type found in dwarf data identified at translation time.  This
> wouldn't be like C++ RTTI dynamic_cast<> but a reinterpret_cast<>.

Hmm, so basically the language syntax for kernel vs user is always going
to be different, so the pattern matchers always distinguish.  I suppose
it's a but inelegant, but it makes it easy to separate the caches (just
need a kernel cache and a user cache).

James