From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125214 invoked by alias); 31 Oct 2019 05:01:15 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 125202 invoked by uid 89); 31 Oct 2019 05:01:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=fcheredhatcom, H*F:U*craig, U*fche, fche@redhat.com X-HELO: mail-lj1-f175.google.com Received: from mail-lj1-f175.google.com (HELO mail-lj1-f175.google.com) (209.85.208.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Oct 2019 05:01:13 +0000 Received: by mail-lj1-f175.google.com with SMTP id q64so5115853ljb.12 for ; Wed, 30 Oct 2019 22:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zjfHQZrotIQX0C+4AkxFMvsPUaMo2xxar0y58WWm6C4=; b=ClTEFs6w/bKaN0DNKH2xAV067CHn/Tv38mOinutHhN7OuWSZxwSvLf3UtH6gEWJ2C7 rPdtCDBEOALlWG8WKsL0eRFjHvIWZmIt8BDpPiwNqjyU6ygQj0GD8iECS42v95OOWqU+ t6NkOEKJEWLdiJumy6ym4EOa6+yP4WrUbCj1ZWOq92KQ598xCPfEtGvJFXHjijYo7ptJ ef7/zvop+6yY8ZOPKlvWQYY8PbFcHM62EbfdK47Tg52n0E2eYOfE0KK5JSZAicKQJzsu aGqTjDcXyVURc+tPHN+N1r7q36PwGl0BLxcvZYXuhl8Y7528RSIginr+xrNax910dvxh hvkQ== MIME-Version: 1.0 References: <8736f9g9sq.fsf@redhat.com> In-Reply-To: <8736f9g9sq.fsf@redhat.com> From: Craig Ringer Date: Thu, 31 Oct 2019 05:01:00 -0000 Message-ID: Subject: Re: Path resolution inconsistency between process("binary") and @var("var@cu","module") To: "Frank Ch. Eigler" Cc: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00021.txt.bz2 On Thu, Oct 31, 2019, 06:15 Frank Ch. Eigler 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.