From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21509 invoked by alias); 8 Nov 2019 04:15:59 -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 21446 invoked by uid 89); 8 Nov 2019 04:15:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Enterprise, also=c2, H*c:alternative?= X-HELO: mail-lj1-f171.google.com Received: from mail-lj1-f171.google.com (HELO mail-lj1-f171.google.com) (209.85.208.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2019 04:15:47 +0000 Received: by mail-lj1-f171.google.com with SMTP id q2so4684930ljg.7 for ; Thu, 07 Nov 2019 20:15:31 -0800 (PST) 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=uYg+atOzYaJ4Nez6xcYmhAFKvVIw89uGTnSBLrh9DXI=; b=s7MjTliX833V/sez90FUM7yyRwm+QwIxih1GYFKsgITG2MQJNLtmd8RywhcRsIAkyd W0G155nQhgeu34RPquG8ehIDGuQZRpyE9Dgo8r7rMjSax6oBNa+tjptziNPw5SD75Ncy DT9HPZGqe1eWCBUr0dxVFF3fvy1QTgwLFB/ncBx3Iw0f5haVyJMWdJ0RbZmSkKa4r6IN RmkoumEkN67BP3yN/cbLTzexzHq3vucv7h6HkPmr8UFdZtX9KcTgTHfDQd4tmtYfVd9v fm8k4RcloE5M7cQQOtF56QN4fvTqTLEkOxgXhqHDqVJtQfZshg6OunKgIWJzbi310wbt a4+Q== MIME-Version: 1.0 References: <87bltyf0zp.fsf@redhat.com> <20191107185157.GA19461@redhat.com> In-Reply-To: <20191107185157.GA19461@redhat.com> From: Craig Ringer Date: Fri, 08 Nov 2019 04:15:00 -0000 Message-ID: Subject: Re: Newbie Notes To: "Frank Ch. Eigler" Cc: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00032.txt.bz2 On Fri, 8 Nov 2019 at 02:52, Frank Ch. Eigler wrote: > Hi - > > > > OK. Take this script, which will work on anything you have lying around > > with simple adaptations: > > [...] > > Ah. Yes, the unused-variable warnings are suppressed, but only for > script located in a tapset. If you put that first alias definition > into a separate directory/file, and run with stap -I$dir, then you > will not see those warnings. > Aha. Makes sense. I can work around the PATH issues with @var etc by generating a .tapm script with the paths templated in, then use that in a tapset that defines the probe aliases etc. That'll work well enough that I think I can prepare a usable tapset for PostgreSQL. (Ideally stap would only warn if a variable was unused across all references to an alias. So if any probe body used the alias-defined variable it wouldn't warn. But from my initial reading of the relevant code that doesn't look simple.) > The issue is specifically within @var and @cast expansion. It's done > early, > > and doesn't appear to benefit from implicit string concatenation at all, > > macro-expanded or otherwise. Per my other post. [...] > > but not this (where $1 = /usr/pgsql-11/ ): > > > > @define PGBIN %( @1 "bin/postgres" %) > > function get_pgver:long() { > > return @var("server_version_num@guc.c", @PGBIN); > > } > > probe process(@PGBIN).function("PostgresMain") { > > printf("%s", @PGBIN, get_pgver()); > > } > > OK, working on this bug. > Cool. I dug through a fair bit of code without figuring it out, sorry :S Want me to open a github issue? I've started working around this in two ways: 1. If possible use @cast and @var only in probe bodies, including aliases, chaining aliases etc where required, bypassing the issue with module context in functions entirely; or 2. Where that's not possible, generating a stub .stpm that defines the required full executable paths from a wrapper script, Makefile, etc, then using those macros in the main tapset. I'll be stuck being backward compatible for a while so I had to work around it anyway... > > [...] I'm talking about how --monitor decides what is / isn't a > > hit. Does using "next" in a probe alias body suppress it? etc. > > It should count every distinct probe whose handler starts executing, > so definitely include those that run through to a 'next'. > Cool. I guess in that case I'd ideally like a way to suppress a probe hit, so the probe body can say "nah, actually this isn't what I'm looking for". But it's hardly important, and if I need it I can write it, so consider it a vague handwavey idea only. > > As a heavy user of perf's "perf top", stap's --monitor is of great > interest > > to me. > > By the way, see also stap --example eventcount.stp > > Thanks. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise