[Bug translator/25346] support enum context variables

["craig.ringer at 2ndquadrant dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25346

--- Comment #4 from Craig Ringer <craig.ringer at 2ndquadrant dot com> ---
Frank,

That's a really good idea.

Ideally projects could make life easier for tools like systemtap by putting
their enums and any required macros into separate header files without any
prerequisites. But in practice few if any large projects are likely to do
this willingly.

I'd I understand you correctly you suggest that stap or some preprocessing
tool could extract relevant macros and enums from debuginfo into a
generated .c file, where each macro of interest is assigned to a static
const symbol for compile time evaluation. Then compile it separately as a
userspace object file, not as a kernel object. The object file, probably
converted to ELF shared library format, could then be loaded by stap to
look up values for macros and enums using @var .

I reckon that should be possible to implement as a helper tool and a tapset
without changing stap, though not as nicely as would be possible with
language and tooling support in stap proper. So I'll experiment and report
back.

I'll use a gdb python script to generate the .c file from debuginfo. Then a
wrapper to compile it to a .so. Then invoke stap with -d
/path/to/generated/someapp_enumlib.so . To reference the values I'd use
@var("enum_or_macro_name",@SOMEAPP_ENUMLIB_PATH) . Probably behind a
generated tapset wrapper that @define d @SOMEAPP_MACRONAME and
@SOMEAPP_ENUMVALNAME convenience wrappers.

A little clumsy. But it should work. It will probably need a list of macros
to export. Grabbing all macros will be clumsy and prone to issues with
dependencies. It'll need manual tweaking in some cases but that can be done
with mock headers in an include path searched before the real ones, a
prelude .h that's always included first and a prelude .c that's included
after all headers, before the generated sources.

Should be easy enough to support pattern matching of wanted enums and
macros by regexp on token name, typename for enums, and/or defining file.

Will give it a go and report back.

Main advantage would be macro evaluation and enum value expression would be
done by the compiler.

I suspect the "right" way to do this is probably to embed LLVM and use
clang to evaluate expressions and macros at runtime during stap execution.
But that's beyond the scope of anything I can justify working on right now.

On Fri, 18 Dec 2020, 20:29 fweimer at redhat dot com, <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=25346
>
> Florian Weimer <fweimer at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |fweimer at redhat dot com
>
> --- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
> Maybe it would also be useful to add a way to compute a constant using a
> userspace expression.  Basically, generate a C source file like this
>
> int systemtap_expression_1 = <<insertion expression 1 here>>;
> int systemtap_expression_2 = <<insertion expression 2 here>>;
>
> Compile this to an object file, and extract the constant from there.
>
> Or use inline asm and search for some marker string around the constants
> that
> were spliced in using inline asm arguments.
>
> This would work for arbitrary C expressions that evaluate to compile-time
> constants, and it sidesteps the kernel vs userspace context issue.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.