Re: Command line systemtap macro setting

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

On Fri, 15 Jan 2021 at 10:18, Craig Ringer <craig@2ndquadrant.com> wrote:

> On Wed, 13 Jan 2021 at 23:04, Frank Ch. Eigler <fche@redhat.com> wrote:
>
>> Hi -
>>
>> > Any thoughts on this? I'd be happy to submit a patch but I'd like to
>> know
>> > if you think it's reasonable to do first, so I don't spend the time
>> writing
>> > something that won't be committable.
>> > It'd be a big usability improvement in systemtap for me to be able to
>> > define systemtap language macros on the command line.
>>
>> Thanks so much for doing the Work!  It's certainly a reasonable
>> self-serve kind of way to do it outside the tool.
>>
>> I really think tho that stap translator proper should do this, and am
>> pretty sure we can.  It'd be some hacking around within tapsets.cxx or
>> loc2stap.cxx or somesuch, but it wouldn't be too much.  The enum
>> values for $FOO_BAR could translate straight to literals.  Would you
>> have any interest in trying to hack on that?
>>
>
> I made an attempt at doing this by implementing an @enum language feature,
> but landed up getting totally bogged.
>
>

Note that @enum wouldn't help with macros.

For them we'd need -ggdb3 builds of the target binaries, probably processed
by dwz, which is sadly not yet standard in packages but is easy enough to
build when required. And we'd need a way to evaluate simple
const-expressions in macros.

One possible approach for macro expression evaluation would be to let the C
compiler that processes the tap module evaluate the macros, such that with
something like:

     @c_macro(FOO)

it might expand to the code:

     (%{ (<<literal text of C macro FOO from DWARF>>)  %})

so if the original C program defined

    #define FOO 2<<4

the generated stap code would be

    (%{ (2<<4) %})

But  that would not work if FOO referenced other macros, or if its
expression evaluated to a different value in kernel code to user code,
referred to typedefs or types not available, etc. Consider for example
macros based on sizeof() or offsetof(). It could also be quite unsafe.

A safer option would probably be to use something like LLVM to evaluate the
macro-expressions in the stap executable during code expansion. But that's
way beyond the scope of anything I can tackle right now, and could still
have issues with missing types, different include paths, different compiler
options, etc affecting the expansion of nontrivial macros.

The only reasonably reliable way I can see of handling macros is getting
the help of the target program. Perhaps systemtap's 'dtrace' script or an
auxillary could automate this though. If this was done as a "macros.d" for
example, one might write:

    # file macros.d
    #include "application_headers_needed.h"
    provider "foo" {
        string_macro("BAR");
        macro("int","BAZ");
    }

and the dtrace script might process it to a macros.c file:

    #include "application_headers_needed.h"

    extern const char _stp_macro_foo_BAR[] __attribute__ ((section
(".stap.macros")));
    const char _stp_macro_foo_BAR[] __attribute__ ((section
(".stap.macros"))) = (BAR);

    extern const int BAZ __attribute__ ((section (".stap.macros")));
    const int BAZ __attribute__ ((section (".stap.macros"))) = (BAZ);

which the program would then compile and link.

The same approach would make it possible for <sys/sdt.h> to expose
STAP_MACRO helpers for use in program code directly, like

    #define SHOULD_BE_AN_ENUM 4

    #include <sys/sdt.h>

    STAP_MACRO(int,SHOULD_BE_AN_ENUM);

It's not as transparent as I'd like, but people seem to cope ok with
probes.d, it'd be possible to autogenerate it for many programs, it'd be
relatively easy to add, and no debuginfo at all would be required.

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