From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4AE7A393D01B; Wed, 6 Jan 2021 00:58:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4AE7A393D01B From: "craig.ringer at 2ndquadrant dot com" To: systemtap@sourceware.org Subject: [Bug translator/25346] support enum context variables Date: Wed, 06 Jan 2021 00:58:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: craig.ringer at 2ndquadrant dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 00:58:49 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25346 --- Comment #4 from Craig Ringer --- 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=3D25346 > > Florian Weimer changed: > > What |Removed |Added > > -------------------------------------------------------------------------= --- > CC| |fweimer at redhat dot com > > --- Comment #3 from Florian Weimer --- > 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 =3D <>; > int systemtap_expression_2 =3D <>; > > 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. --=20 You are receiving this mail because: You are the assignee for the bug.=