[Bug translator/25346] New: support enum context variables

[Bug translator/25346] New: support enum context variables

[fche at redhat dot com]

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

            Bug ID: 25346
           Summary: support enum context variables
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

It would be helpful to have stap resolve enum values from the target context:

enum foo { bar, baz };
int main () {}

stap -e 'process.function("main") { println($bar) }'

This can enable a variant of @const that is possible to wrap in an
if(@defined()) guard, and thus provide new compatibility mechanisms.

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

[Bug translator/25346] support enum context variables

[craig.ringer at 2ndquadrant dot com]

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

Craig Ringer <craig.ringer at 2ndquadrant dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |craig.ringer at 2ndquadrant dot co
                   |                            |m

--- Comment #1 from Craig Ringer <craig.ringer at 2ndquadrant dot com> ---
Created attachment 13061
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13061&action=edit
WIP @enum support

Here's the WIP I have on @enum support

I got pretty bogged on it, and don't expect to be able to progress any time
soon, but maybe it'll help someone else.

When working on it, I found it quite hard to unravel the various visitors and
what they were for, what exactly they implemented etc. There are some
semi-related comments scattered through the patch where I added notes on things
I was trying to understand.

The main interesting bits are dwflpp::iterate_over_enumerations and 
dwarf_atenum_query

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

[Bug translator/25346] support enum context variables

[craig.ringer at 2ndquadrant dot com]

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

--- Comment #2 from Craig Ringer <craig.ringer at 2ndquadrant dot com> ---
It's also worth noting that a lot of code uses #define macros not true enums .

While embedded C blocks can #include C headers, they can only do so if the
header is safe and sensible to compile as kernel code, with no reference to
standard headers. For many programs this may not be feasible.

At best, the macro definitions can be extracted into a separate mini-header for
systemtap use.

An @enum that used DWARF debuginfo would be fantastic, but would only help for
true enums.

If code is compiled with -ggdb3 it will include DWARF macro information too. In
that case, it becomes possible to look up the textual definitions of macro
symbols, though recursive expansion is not trivial to handle in cases where the
macro is defined in terms of other macros. If the macro expansion can be used
as a valid C const-expression, it could be evaluated with an embedded-C
expression and stored in a static constant, such that some @dwarf_macro("FOO")
or @dwarf_macro("FOO@bar.h") or @dwarf_macro("FOO","/path/to/program") for
macro "#define FOO 1<<4" could expand to definition:

    %{
    static const long _stap_macro_FOO = (1<<4);
    %}

and where referenced expand to %{ _stap_macro_FOO %} .

I had intended to tackle this after I got @enum working, but I got stuck trying
to work out how do make @enum work.

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

[Bug translator/25346] support enum context variables

[fweimer at redhat dot com]

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 the assignee for the bug.

[Bug translator/25346] support enum context variables

[craig.ringer at 2ndquadrant dot com]

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.

[Bug translator/25346] support enum context variables

[craig.ringer at 2ndquadrant dot com]

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

--- Comment #5 from Craig Ringer <craig.ringer at 2ndquadrant dot com> ---
On Wed, 6 Jan 2021 at 08:58, Craig Ringer <craig.ringer@2ndquadrant.com>
wrote:

> Will give it a go and report back.
>
>
Posted to the ML since it's kind of orthogonal to this ticket.

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

[Bug translator/25346] support enum context variables

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scox at redhat dot com
             Status|NEW                         |ASSIGNED

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

[Bug translator/25346] support enum context variables

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Stan Cox <scox at redhat dot com> ---
1ef2edcd3: Add support for accessing enumerators

Interesting ideas about alternate constant support; this patch is limited to
enumerators.  Also wondered if $Color$ to list all enumerators might be useful.
 e.g. enum Color { red, green = 20, blue };
      probe process.function("main").label("RETURN") {printf("green=%d
%d\n",$green,@defined($orange))}
      => green=20 0

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