From: Craig Ringer <craig@2ndquadrant.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: Newbie Notes
Date: Fri, 08 Nov 2019 04:15:00 -0000 [thread overview]
Message-ID: <CAMsr+YENsoK3jpyHKmdLd_Xz561mrCFu=eqy9+thu-4ba7Fh0w@mail.gmail.com> (raw)
In-Reply-To: <20191107185157.GA19461@redhat.com>
On Fri, 8 Nov 2019 at 02:52, Frank Ch. Eigler <fche@redhat.com> 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
next prev parent reply other threads:[~2019-11-08 4:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-28 7:19 Craig Ringer
2019-10-28 8:55 ` Craig Ringer
2019-10-30 20:10 ` Frank Ch. Eigler
2019-10-31 14:01 ` Craig Ringer
2019-11-07 18:52 ` Frank Ch. Eigler
2019-11-08 4:15 ` Craig Ringer [this message]
2019-11-08 12:03 ` Frank Ch. Eigler
2019-11-10 5:05 ` Craig Ringer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMsr+YENsoK3jpyHKmdLd_Xz561mrCFu=eqy9+thu-4ba7Fh0w@mail.gmail.com' \
--to=craig@2ndquadrant.com \
--cc=fche@redhat.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).