This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Newbie Notes
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Craig Ringer <craig at 2ndquadrant dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 7 Nov 2019 13:51:57 -0500
- Subject: Re: Newbie Notes
- References: <CAMsr+YEm42ERBdSH22=G9X84GvSGiV0ExPkaULyUyGvFqvLAQw@mail.gmail.com> <87bltyf0zp.fsf@redhat.com> <CAMsr+YEJUuncM_XB2WM=gk9ja2MeaqYBj6swzjG=CnmmcPQtWw@mail.gmail.com>
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.
> 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.
> [...] 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'.
> 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
> [...]
- FChE