Re: SDTs with data types and argument names

[Craig Ringer <craig@2ndquadrant.com>]

On Fri, 10 Jan 2020 at 02:46, Frank Ch. Eigler <fche@redhat.com> wrote:

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

Good to know. Any idea who may've been involved? It'd be good to
collaborate and not duplicate work or explore a dead-end already followed.


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

Indeed. And the latter option is hairy for complex and portable software:
you must get exactly the right header version, but you must also ensure you
have any number of preprocessor macros etc set precisely the same. There
can be header inclusion order considerations and more. I'm very reluctant
to use the automated header processing features.

Without debuginfo we'd still get useful probe names, which would IMO be
exceedingly useful. stap could expose them as $theArgName and still expose
them as $arg1 etc for BC, so that wouldn't upset anyone. It might also let
stap handle narrower integer types better. And *if* debuginfo was present,
it could allow the user to traverse structs etc via
$theArgName->member->foo .

I don't know of any way to ask gcc/gdb/binutils/etc to retain a subset of
debuginfo in an executable when it's being stripped, and I doubt that'd be
popular or accepted anyway. Where would you stop? In many cases the
immediate struct would be of little value without type info for its member
types and their member types and so on. So I realise that it's no
substitute for debuginfo, and doesn't make it possible to get full
functionality without it.

What it _should_ do is put static probes on an equal footing with DWARF
probes when debuginfo is present. Right now they're inferior in quite a
number of ways: no argument names, no argument types without explicit and
verbose casting, representations in monitor mode are hex statement
positions not probe names, and more.

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

I'll look into that.

This won't be something I can leap to do in a hurry as I have to fit it in
bits and pieces around main deliverables. I'm sure you know the feeling.
But I'm keen to work on it when I get the chance.

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