Re: Newbie Notes

[Craig Ringer <craig at 2ndquadrant dot 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