Re: [PATCH] fix alias cache breakage

["Frank Ch. Eigler" <fche at redhat dot com>]

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.


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

- FChE