Re: SDTs with data types and argument names

[fche at redhat dot com (Frank Ch. Eigler)]

Hi -

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

Yeah.  I believe there was a kernel-bpf-oriented group last year, who
were speculating extending sdt.h in a similarly motivated way.


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

Note that one point of the sdt.h structure was to make the executables
self-sufficient with respect to extracting this data, even if there is
no debuginfo available.  Adding type names can only work if that
debuginfo is available after all, or else if it's synthetically
generated via @cast("<foo.h>") type constructs.


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

Yeah, that's a sensible way of doing it, without creating a new note
format or anything.  It's important that the section be marked with
attributes that will force it to be pulled into the main executable
via the usual linker scripts.

> [...]
> 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.

(FWIW, I wouldn't consider it a failure if the typeinfo has to be
manually added.)


- FChE