public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* SDTs with data types and argument names
@ 2019-12-19  3:00 Craig Ringer
  2019-12-20  4:13 ` Craig Ringer
  2020-01-09 18:46 ` Frank Ch. Eigler
  0 siblings, 2 replies; 6+ messages in thread
From: Craig Ringer @ 2019-12-19  3:00 UTC (permalink / raw)
  To: systemtap

SystemTap has inherited the dtrace decision to give SDTs anonymous
arguments of type 'long' and generic names like arg1, arg2, etc.

This makes sense if you're trying to be DTrace compatible, but I don't
think stap is really trying to be very dtrace-like at runtime.

It'd be great to capture the probe argument names and their data types to
systemtap when SDTs are generated from a probes.d file. It'd make sense to
expose this capability for when probes are defined with STAP_PROBE(...) etc
in their own builds too.

The goal is to let you write

probe process("myapp").mark("some__tracepoint")
{
    printf("hit some__tracepoint(%s, %d)\n",
        user_string(useful_firstarg_name),
        some_secondarg->somemember->somelongmember);
}

and display useful arg names and types in `stap -L` too.

Saving the argument names looks relatively simple in most cases. Define an
additional set of macros in the usual STAP_PROBE2() etc style like the
following pseudoishcode:

    STAP_PROBE2_ARGAMES(provider, probename, argname1, argname2) \
        const char "__stap_argnames_" ## provider ## "_" ## probename ##
[2][] \
              = { #argname1, #argname2 } \
        __attribute__ ((unused)) \
        __attribute__ ((section (".probes")));

i.e generate some constant data with the probe names in a global array we
can look up when compiling the tapscript based on the provider and probe
name.

The 'dtrace' script could emit these automatically into the generated
probes.h and the compiler would de-duplicate them at link-time. But it'd be
cleaner if they were embedded into the .o optionally generated by the
dtrace script.

A nearly identical approach could be used to give systemtap access to the
textual datatype names for probes declared in probes.d. Or we could even
use gcc's __typeof__ to derive them.

Applications that wanted to expose type and arg info for probes would have
to do so explicitly by invoking STAP_PROBEn_ARGAMES(...) and
STAP_PROBEn_ARGTYPES(...) with the names and types of the probe somewhere
in global scope, outside the probe callsite. Which is a bit inconvenient,
but not that hard.

That is, unless there's some way we can escape the function scope in which
the STAP_PROBEn(...) macro is invoked and define global symbols. I've asked
for ideas about that here: https://stackoverflow.com/q/59402666/398670 .
If that's possible then ideally I'd like to use the gcc __typeof__ operator
to autogenerate typed symbols for each argument or to generate a
const array of type names. Also to have a variant that uses token pasting
to derive the argument names automatically, though we'd still need a
variant that lets you specify them explicitly for when the args are
expressions not simple variable name tokens.

So my hope is it'll be possible to write

    STAP_PROBE2(myprovider, myprobe, thing->foo, "foo", get_something(),
"something");

and have stap record the supplied argnames and infer the typeinfo then
record that too, so it can look it up during tapscript translation. Instead
of

    x = user_string($arg1)
    y = @cast(arg2, "SomethingType@my.c","/path/to/myprogram")->somevalue

you'd be able to write

    x = user_string($foo)
    y = $something->somevalue

and perhaps even more importantly, `stap -L` could show useful type and
argname info for probes so they'd serve as documentation of sorts.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-13 21:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-19  3:00 SDTs with data types and argument names Craig Ringer
2019-12-20  4:13 ` Craig Ringer
2020-01-09 18:46 ` Frank Ch. Eigler
2020-01-13  5:28   ` Craig Ringer
2020-01-13 20:54     ` Frank Ch. Eigler
2020-01-13 21:08       ` Frank Ch. Eigler

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).