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


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


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


- FChE


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