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

[Craig Ringer <craig@2ndquadrant.com>]

On Thu, Oct 31, 2019, 06:15 Frank Ch. Eigler <fche@redhat.com> wrote:

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

Makes sense.

Pretty critically reduces the utility of functions though.

@uvar(...) and @ucast(...) like the convention elsewhere would make sense
for user vs kernel ambiguity. Or an extra optional argument specifying
resolution.

PATH resolution should be stable within a tap run so there isn't much
concern about differing resolutions in differing places.

I reckon I could implement that.