Re: Path resolution inconsistency between process("binary") and @var("var@cu","module")

[fche at redhat dot com (Frank Ch. Eigler)]

craig wrote:

> [...]
> The working cases are, for some probe on a function/statement in a
> userspace executable:
>
> - @var("sym@CU") directly in a probe; doesn't require module argument at all
> - @var("sym@CU", "/full/path/to/executable") in a function() called by
> a probe: finds var
>
> The failing cases are, all when in a function() called by a probe of a
> userspace executable:
>
> - @var("sym@CU") in the function: reports missing symbol, tries to
> resolve in "kernel"
> - @var("sym@CU","executable") in the function: also tries to resolve in kernel

The reason for this is that a function does NOT have a probe context
relative to which it can do dwarf symbol resolution.  It does not
operate on some sort of auto-inherited context from its caller probe
handler(s) and/or function(s).  So, disambiguation of kernel-space
(including module names!) vs.  user-space (executables) is left up to a
simple naming convention in the function you found.  Having a $PATH
based search would improve convenience at the cost of reintroducing
ambiguity.  Not sure whether that's worth it, are you sure it is?


- FChE