From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id C234F38708F8 for ; Fri, 15 Jan 2021 02:38:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C234F38708F8 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=2ndquadrant.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=craig.ringer@2ndquadrant.com Received: by mail-lj1-x22d.google.com with SMTP id y22so8773593ljn.9 for ; Thu, 14 Jan 2021 18:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bSrjVHNaSC/E1RDU1yvbSAA0Pv0hrKNMBAufQnit4uQ=; b=hHrrTgUAEoueik3P7pUYEYNsLEuUOVmvUfaHh06oHHXrHa7GSYsf1ubEyD2miCN1uo tCIMHLbdVjfpfAH8x7uvYOQUx0dqcFQwH8p6EMK6mRLknwN87BODCJ4yedwj/BNyT/fd UaPzTnj6omUeqnKF0Jw61pBiF9C1zZZ/krYQAe9MYVwG9B07oYpMatw4AJW1DsrHmKmP AMKyfsX5PG0qQXASxypoiNsULTkITsWL3+TsAmbjsiiXfPsfgJF6kMekOf+QyLmHRdzx 8UrsgcjXrm8T4eWoiGlGxu8dkzXjZXAWhwr9C4V5+jjUGRl8HgMRESjrvy0b6WHZgBkb sUbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bSrjVHNaSC/E1RDU1yvbSAA0Pv0hrKNMBAufQnit4uQ=; b=c/9HdkTpaBKkuJSm9HSTOa0AjAyhf1VHr0Nt/HF+SfO814WG/Wy2U1ceRqwZbCqniN zGETuQPmfUVW/xU0RUlO+s3TtkdB0JGZtxwQeYYQFnqN586T459Tp3D7Mkqk1Cz5gD/f WmDwcGvOv0uPO99WqAAGRFHwQ8aVZmNEWVK6HHLL2wAcj0fTX1HrD2ozkL5ndtge3M0U qnq6Loezplm8TS1Wo4EUXTZ771KUlSk4nI8KZU4GjWA+lLEDMsrpvnvKarw16n3TWlwh hUT74I3fyOobFm+6hE2QBAsJGxoWP3r8wzkDYk81wPLC5HpDqBx3dTOI9HUups4ZpWKa bgpQ== X-Gm-Message-State: AOAM532GrRhy9wTwZ814hJtw68QMKyW32TdBwCFxVSXgCYd+8cefNQXo V9KAMzr/OqmP4xa0cY/q+TsIyu/w/ljNK93qTZ/8Og== X-Google-Smtp-Source: ABdhPJwbNn5oIiC+1y9lwOPcUMyS42Vhd83u3ifXctQBpJABMFX2rw3O3neDJTdnlAzdjY6j0Mz00RWpyEp1RTtuNZE= X-Received: by 2002:a05:651c:1254:: with SMTP id h20mr4363449ljh.211.1610678304385; Thu, 14 Jan 2021 18:38:24 -0800 (PST) MIME-Version: 1.0 References: <20210113150431.GC25762@redhat.com> In-Reply-To: From: Craig Ringer Date: Fri, 15 Jan 2021 10:38:13 +0800 Message-ID: Subject: Re: Command line systemtap macro setting To: "Frank Ch. Eigler" , systemtap@sourceware.org X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Fri, 15 Jan 2021 02:38:29 -0000 On Fri, 15 Jan 2021 at 10:18, Craig Ringer wrote: > On Wed, 13 Jan 2021 at 23:04, Frank Ch. Eigler 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: (%{ (<>) %}) 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 to expose STAP_MACRO helpers for use in program code directly, like #define SHOULD_BE_AN_ENUM 4 #include 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