From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by sourceware.org (Postfix) with ESMTPS id CA1963857C4C for ; Tue, 21 Jul 2020 02:54:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CA1963857C4C 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-x241.google.com with SMTP id r19so22338536ljn.12 for ; Mon, 20 Jul 2020 19:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=urp/+vtwkbUbiaYrJxrE+CZu/H67BfLUJ2qsLVKk9HM=; b=QSZGehxygeMABlXXYs2LQNzQkb7KSiZ4sP1+6lRw0LTJyXFTZyAY2Z+iRA5sgIhPH0 HvXgPp21gejdttaegHdB/orMYqKbyt+GmXkwJwzqZjmN1wO7aGee4+UaA0kxImkt0sr6 sCfF7TOI3axY1E+/bHx0fGSnL1HgHak3im33eH4xCX5FtBIc4zvn2/1EdTatJmFOBj7j IEFm0Gplq/tqNhqwrgf0Zh/QjKPsaLlflwZJzmoxUWKXcWf0GjKVvQ96IbZsVoDja/fr fp7lCAu1Aku2o9Oxyn4+hVEZlLHhayYeBHZORdkVt5Nokx/9GNO/EXAfo0f9Izj9MqZt vubg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=urp/+vtwkbUbiaYrJxrE+CZu/H67BfLUJ2qsLVKk9HM=; b=EzhxOd1Qk+uteJO9cwi73WQQRDYASPDZ9dtMT/a5Aluk5tR2A8rchUfz0UJ0HVsihi Gupo4JuAo9Zf0ftoYHSKPsWmkvC8gZlutvK33q59Xa2rkPnEfIujG6S1aA5iZcJ3BuUm TYmwqMq7dfv5AS9c+/1P5FlEZhJzukYUDtkAvLvtMRmyUD/vwS3mJh9rV4OeNQNPKzuC h1utKsfsacg5CZDSTSACfwUk89hxRlDijpZ0JVa0Xjw0Ot96yfrlgBbwxhCUuoiT5nbT OHPvfwhPbYm7gAVp6MnYuc/7e3h1t05YzCcorjYI5hSIawMfn8hZ9KxNKmro5TjZdZ82 z7tw== X-Gm-Message-State: AOAM531yaC/8WJzc0foyNc+CDDnnkJBM4RbuMivdoVbNnMU4XzhmhJxP Y04IlEUJimfP8XZRyCqX2oMrpw97A36zBX8O1M3QB+//Q5b940fF X-Google-Smtp-Source: ABdhPJxzLDkkLtBbl5yS029tfvxgdqXQqxBlr5yDlO00ZBf73ohfWnrTVmy+F+iVQHXKL2e2BqOA2SNC9BjwSYjrW2Y= X-Received: by 2002:a05:651c:231:: with SMTP id z17mr11309627ljn.163.1595300076731; Mon, 20 Jul 2020 19:54:36 -0700 (PDT) MIME-Version: 1.0 From: Craig Ringer Date: Tue, 21 Jul 2020 10:54:25 +0800 Message-ID: Subject: Code maintenance / verbosity: macros, enums, and casts To: systemtap@sourceware.org X-Spam-Status: No, score=-0.8 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: Tue, 21 Jul 2020 02:54:41 -0000 Hi all TL;DR: I'd like to add DWARF-based @enum("foo","my.so") and am interested in whether that'd be potentially mergeable + advice on where in the stap code I might want to start. ------ I'm looking for advice from people more experienced with writing and maintaining real world systemtap tapsets and tools to manage tapset verbosity and make my tapsets reasonably maintainable. As I write most stap code I'm increasingly finding that I produce a lot of boilerplate, especially for member access via a @cast or @var, for mapping enums to their long values; for mapping scalar integer macros to their long values; for mapping the values of various enums back to their symbolic names; and for comparing with C "char" literals. Constants are definitely the biggest one right now. In addition to their verbosity, if they're maintained in tapsets instead of looked up from the probed code there's a risk that the tapset's idea of a given enum or macro definition may not match what the code is using. I write a lot of tapset boilerplate like: @define FOO_BAR %( 0 %) @define FOO_BAZ %( 0x63 %) // 'c' @define FOO_BAK %( 0x64 %) // 'd' function foo_str:string(foo:long) { if (foo == @FOO_BAR) return "BAR" if (foo == @FOO_BAZ) return "BAZ" if (foo == @FOO_BAK) return "BAK" } Add @enum("FOO_BAR", "my.so") ==== If these are defined in the sources as an enum, it'd be great to look them up at stap compile time with a new @enum construct. I'm wondering how feasible this might be and where I should start looking if I want to try implementing it. Enums are guaranteed to be evaluated to a constant value and they're in the ELF .debug_info section. So there's no need to for the executable to have -g3 / -ggdb3 debuginfo, the default is fine. And there are no problems with evaluating expressions, since there's a constant pre-evaluated by the compiler and embedded in the debuginfo. I can get enum info with eu-readelf --debug-dump=info mylib.so though I'm still trying to understand the elfutils / libdw api well enough to actually access it... Why not @const? ==== I'm aware of "@const" but there are a number of reasons it doesn't help me: * It needs guru mode, which is really not desirable on production systems (or you need to preinstall a tapset that exposes the constants which then defeats the point); * It doesn't provide a way to specify the header(s) to include to find the constant, you have to handle that externally via a tapset or an explicit guru-mode #include . * man stap says "headers are built with default GCC parameters"; this means there's no guarantee the values stap sees match what the program was compiled with; * It requires full headers of the probed lib/program to be available at probe compile time, *including* transitive dependency headers included by the program/lib headers, which is not always desirable or possible; * The headers must be safely include-able including any/all headers they include in turn, any required preprocessor definitions, etc. Some headers have specific order-of-inclusion rules, may define or redefine symbols that should not be exposed, etc; * "stap" doesn't appear provide a simple way to specify the include path to search for such headers What about macros? ==== Macros are harder. They're only present if -g3 or -ggdb3 was used at build-time, which is still not the norm even though the results are much more compact now than they used to be. Most packages don't use dwz to compact their debuginfo either. Even if present in the .debug_macro ELF section, the macro definitions may be arbitrary C expressions. They are not guaranteed to be literal integers or strings. gdb knows how to evaluate expressions when attached to a process, but I don't think it can do so statically. So using macro definitions from debuginfo will only work in cases where the macro definition is simple. It'd still be really handy. There's eu-readelf --debug-dump=macro some.so and there's libdw's dwarf_getmacros() etc so the foundations are there. I'd definitely want to start with @enum first though. Then only add a @dwarf_macro later, if feasible, and probably restricted to simple numeric or string literals. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise